Re: [9front] unofficial sdcard image for raspberry pi 4 testing

Re: [9front] unofficial sdcard image for raspberry pi 4 testing

[cinap_lenrek]

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

Re: [9front] unofficial sdcard image for raspberry pi 4 testing

[Steve Simon]

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

hjfs

[Ethan Gardener]

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.

Re: [9front] hjfs

[Stanley Lieber]

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

Re: [9front] unofficial sdcard image for raspberry pi 4 testing

[hiro]

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 :)