9front - general discussion about 9front
 help / color / mirror / Atom feed
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).