* Re: [9front] unofficial sdcard image for raspberry pi 4 testing
@ 2019-10-20 0:37 cinap_lenrek
2019-10-20 9:13 ` Steve Simon
0 siblings, 1 reply; 6+ messages in thread
From: cinap_lenrek @ 2019-10-20 0:37 UTC (permalink / raw)
To: 9front
9front has a generic wifi layer that handles the wifi protocol details such
as logging on to an access point and encryption. richard millers raspberry pi
wifi driver was written in a different environemnt. so our aux/wpa, which is used
to establish encryption keys to a wpa/wpa2 wirelss nework might be incompatible
to richard millers driver.
the error message sounds like the driver does not understand the "essid" control
message wich aux/wpa uses to select the wifi network to scan and associate to
by essid string.
i'm currently moving to spain and have no time to look into this. sorry.
--
cinap
^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: [9front] unofficial sdcard image for raspberry pi 4 testing
2019-10-20 0:37 [9front] unofficial sdcard image for raspberry pi 4 testing cinap_lenrek
@ 2019-10-20 9:13 ` Steve Simon
2019-10-20 13:40 ` hjfs Ethan Gardener
2019-10-20 13:48 ` [9front] unofficial sdcard image for raspberry pi 4 testing hiro
0 siblings, 2 replies; 6+ messages in thread
From: Steve Simon @ 2019-10-20 9:13 UTC (permalink / raw)
To: 9front
hi all,
can anyone give me an opinion on hjfs,
i am interested in how it compares to, say, cwfs.
Also, i would like to know whether hjfs is ready for “production” use - its manpage indicates it it exoerimental, is that still the case?
-Steve
> On 20 Oct 2019, at 2:38 am, cinap_lenrek@felloff.net wrote:
>
> 9front has a generic wifi layer that handles the wifi protocol details such
> as logging on to an access point and encryption. richard millers raspberry pi
> wifi driver was written in a different environemnt. so our aux/wpa, which is used
> to establish encryption keys to a wpa/wpa2 wirelss nework might be incompatible
> to richard millers driver.
>
> the error message sounds like the driver does not understand the "essid" control
> message wich aux/wpa uses to select the wifi network to scan and associate to
> by essid string.
>
> i'm currently moving to spain and have no time to look into this. sorry.
>
> --
> cinap
^ permalink raw reply [flat|nested] 6+ messages in thread
* hjfs
2019-10-20 9:13 ` Steve Simon
@ 2019-10-20 13:40 ` Ethan Gardener
2019-10-20 15:26 ` [9front] hjfs Stanley Lieber
2019-10-20 13:48 ` [9front] unofficial sdcard image for raspberry pi 4 testing hiro
1 sibling, 1 reply; 6+ messages in thread
From: Ethan Gardener @ 2019-10-20 13:40 UTC (permalink / raw)
To: 9front
On Sun, Oct 20, 2019, at 10:13 AM, Steve Simon wrote:
> hi all,
>
> can anyone give me an opinion on hjfs,
> i am interested in how it compares to, say, cwfs.
You can use hjfs in a 1GB disk image, where 12GB is the minimum recommended for cwfs because it needs several partitions.
hjfs dump is very fast because it simply marks files copy-on-write. cwfs copies files to another partition on dump. Not a big deal since cwfs normally dumps at 5am. hjfs doesn't have a built-in scheduler, you'd have to trigger dumps with cron if you want that.
as far as i know, hjfs tends to fragmentation, and i don't think it has a defragmenter. cwfs dump can't fragment, and its cache can be defragmented with a dump-restore cycle.
> Also, i would like to know whether hjfs is ready for “production” use -
> its manpage indicates it it exoerimental, is that still the case?
I've barely used hjfs, but have heard good things about it; lots of people use it. It's not like cwfs is perfect anyway; it will crash if the cache partition fills, potentially losing a day's work. its design makes it hard to determine free space in the cache. hjfs has only one partition and can correctly compute free space. I never filled my cache, I'm quite a light user of disks, but did see a corrupted file once, in 10 years use. I got it back from the dump, but didn't try to find the last good version.
^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: [9front] hjfs
2019-10-20 13:40 ` hjfs Ethan Gardener
@ 2019-10-20 15:26 ` Stanley Lieber
0 siblings, 0 replies; 6+ messages in thread
From: Stanley Lieber @ 2019-10-20 15:26 UTC (permalink / raw)
To: 9front
9front.org/cat-v.org run on hjfs:
- everything is one partition.
- 4kb blocks (cwfs defaults to 16kb).
- dump is triggered manually (cwfs is hardcoded at 5am).
- fragmentation.
my unscientific anecdotal claim is that cwfs is faster, but hjfs is more flexible and forgiving of resource constraints such as limited disk space and the inability or unwillingness to babysit cache/dump as the physical disk fills up.
sl
^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: [9front] unofficial sdcard image for raspberry pi 4 testing
2019-10-20 9:13 ` Steve Simon
2019-10-20 13:40 ` hjfs Ethan Gardener
@ 2019-10-20 13:48 ` hiro
1 sibling, 0 replies; 6+ messages in thread
From: hiro @ 2019-10-20 13:48 UTC (permalink / raw)
To: 9front
the main thing that prevents production usage of hjfs is that there is
no file system check tool to help you out in case something goes
wrong.
otherwise many people have used it quite successfully for small VM
installations with only limited or expensive storage.
manual backups recommended :)
^ permalink raw reply [flat|nested] 6+ messages in thread
* hjfs
@ 2012-08-07 16:27 Julius Schmidt
0 siblings, 0 replies; 6+ messages in thread
From: Julius Schmidt @ 2012-08-07 16:27 UTC (permalink / raw)
To: 9front
[-- Attachment #1: Type: text/plain, Size: 1392 bytes --]
I just committed a new file system for 9front, called hjfs after the
infamous #pragma.
It can be already used as a root filesystem and now needs to be reviewed
and tested.
Please note that it's highly experimental and expect that any data you put
on it may be lost.
(It just crashed here a few minutes after the commit)
I would be happy if someone could review the code and/or test it and report
any (possible) bugs here.
There are no really exciting features (it wouldn't have made a good phd
thesis and it won't make a good reddit post either); it's for the most part
a simplified version of cwfs (about four times smaller in terms of SLOC),
differences being in particular
1. it uses one partition for everything
2. it has refcounting for blocks
3. as a result, dump is very quick
4. it uses lib9p
5. deleted files which are still open continue to exist as "zombies" (with
the DGONE flag set) until they are closed
Planned future features:
1. file system checking (this is vital really)
2. move command to move file trees quickly
3. (perhaps) copy command to copy file trees quickly (copy-on-write)
4. separate attach for commands
5. (perhaps) support for multiple file systems similar to the other file
servers (most of the underlying code already supports this)
6. "pruning" the dump (removing old data)
7. (perhaps) copying the dump in parts from and to other storage media
[-- Attachment #2: Type: text/html, Size: 1608 bytes --]
^ permalink raw reply [flat|nested] 6+ messages in thread
end of thread, other threads:[~2019-10-20 15:26 UTC | newest]
Thread overview: 6+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2019-10-20 0:37 [9front] unofficial sdcard image for raspberry pi 4 testing cinap_lenrek
2019-10-20 9:13 ` Steve Simon
2019-10-20 13:40 ` hjfs Ethan Gardener
2019-10-20 15:26 ` [9front] hjfs Stanley Lieber
2019-10-20 13:48 ` [9front] unofficial sdcard image for raspberry pi 4 testing hiro
-- strict thread matches above, loose matches on Subject: below --
2012-08-07 16:27 hjfs Julius Schmidt
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).