Re: [9front] Questions/concerns on gefs

[ori@eigenstate.org]

Quoth ori@eigenstate.org:
> Quoth Timothy Robert Bednarzyk <mail@trbsw.dev>:
> > 
> > Again, I fully realize that it's not _really_ possible to answer these
> > hypothetical questions before the work to add RAID features to gefs is
> > done, and I would be perfectly content with "I don't know" as an answer.
> 
> I don't know.
> 
> > While I have not had any _issues_ using gefs so far, I have some
> > concerns regarding performance. When I was copying files to my pseudo-
> > RAID 10 fs, the write speeds seemed about reasonable (I was copying from
> > several USB HDDs plugged directly into the server and from the
> > aforementioned NVMe SSD so that I could replace its ext4 filesystem with
> > gefs, and while I didn't really profile the actual speeds, I estimate
> > them to have been around 100 MiB/s based on the total size and the time
> > it took to copy from each drive). However, when I was copying files from
> > the pseudo-RAID 10 fs to the NVMe SSD, I noticed that it took somewhere
> > between 3-4 times longer than the other way around (when the NVMe SSD
> > was still using ext4). Additionally, it took about the same amount of
> > time to delete those same files from the pseudo-RAID 10 fs later.
> > Lastly, I tried moving (rather, cp followed by rm) a ~1 GB file from one
> > directory on the pseudo-RAID 10 fs to another and that ended up taking a
> > while. Shouldn't cp to different locations on the same drive be near-
> > instant since gefs is COW? And shouldn't rm also be near-instant since
> > all it needs to do is update the filesystem itself?
> > 
> 
> There's a lot of low hanging performance fruit -- especially for
> writing and deletion. Writing currently copies blocks a lot more
> than it theoretically needs to, and deletion is O(n) in file size,
> when it could theoretically be O(1) with some complicated code.
> 
> There's nothing in 9p that allows copy to be smart about COW,
> so it isn't.
> 
> https://orib.dev/gefs-future.html
> 

also -- current priority is getting enough miles
on it to be sure there aren't any serious bugs, space
leaks, or other big issues; optimization comes once I'm
happy enough with it to show as an option in the installer