From: ori@eigenstate.org
To: 9front@9front.org
Subject: [9front] The great experimental file shredder
Date: Sun, 23 Jan 2022 18:42:38 -0500 [thread overview]
Message-ID: <1723182A0202ACE64AF510BC55FF4CEC@eigenstate.org> (raw)
Gefs is a new file system for plan 9. It aims to be a
crash-safe, corruption-detecting, performant, and
simple file system that supports modern file systems
features.
Here's a summary of the internals:
https://orib.dev/gefs.txt
Here's the code:
https://shithub.us/ori/gefs/HEAD/info.html
This will allow you to write /adm/users and add your
own users
Currently, it is EXTREMELY experimental. The disk
format is NOT stable, and until it's more battle
tested, there will be NO attempt to keep compatibility
between format changes. Writes are currently extremely
slow, due to implementation shortcuts that haven't yet
been worked thorugh.
However, it's ready for help: The code seems to work,
but it needs testing.
Gefs is designed to support a number of features that
you'd expect from a modern file system: It's copy on
write, crash safe, corruption detecting, snapshotting,
and reasonably performant.
That said, there are a number of known issues with the
current implementation, which need to be fixed before
the file system goes live:
- We are missing a fsck. The 'check' command on the
console exists, but is incomplete.
- Writes are synchronous, and therefore slow.
- The allocation log is not recompressed while the
file system is running.
- It takes allocation log blocks to record data
deletion. If the file system gets full, we have
no blocks to record freeing data.
- OEXEC does not yet take implicit snapshots.
- The fs console is incomplete.
- Many optimizations are not yet implemented. Things
are slower than they should be.
- The cache is allocated with malloc. The max size
is therefore limited, and more global locks than
necessary are taken.
- It needs testing.
I'll be working on all of this, but I'm ready to
take bug reports, patches, and code review.
With all that in mind, if you want to try it out,
you can either use a real disk, or an image:
disk=/dev/sdE0/data
or
dd -if /dev/zero -of test.fs -bs 1kk -count 4k
disk=test.fs
First, ream the disk:
gefs -r $disk
Then set up the user directories so that authentication
works.
gefs -A -u glenda $disk
mount /srv/gefs /n/gefs
mkdir /n/gefs/adm
cp /adm/users /n/gefs/adm/users
echo sync >> /srv/gefs.cmd
kill gefs | rc
Then, run it:
gefs $disk
Thanks, and happy file shredding!
reply other threads:[~2022-01-23 23:50 UTC|newest]
Thread overview: [no followups] expand[flat|nested] mbox.gz Atom feed
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=1723182A0202ACE64AF510BC55FF4CEC@eigenstate.org \
--to=ori@eigenstate.org \
--cc=9front@9front.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
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).