From mboxrd@z Thu Jan 1 00:00:00 1970 X-Spam-Checker-Version: SpamAssassin 3.4.4 (2020-01-24) on inbox.vuxu.org X-Spam-Level: X-Spam-Status: No, score=0.0 required=5.0 tests=none autolearn=ham autolearn_force=no version=3.4.4 Received: (qmail 7681 invoked from network); 23 Jan 2022 23:50:28 -0000 Received: from 4ess.inri.net (216.126.196.42) by inbox.vuxu.org with ESMTPUTF8; 23 Jan 2022 23:50:28 -0000 Received: from mimir.eigenstate.org ([206.124.132.107]) by 4ess; Sun Jan 23 18:42:53 -0500 2022 Received: from stockyard.wework.com ( [65.200.165.210]) by mimir.eigenstate.org (OpenSMTPD) with ESMTPSA id b32eb43d (TLSv1.2:ECDHE-RSA-AES256-SHA:256:NO) for <9front@9front.org>; Sun, 23 Jan 2022 15:42:40 -0800 (PST) Message-ID: <1723182A0202ACE64AF510BC55FF4CEC@eigenstate.org> To: 9front@9front.org Date: Sun, 23 Jan 2022 18:42:38 -0500 From: ori@eigenstate.org MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit List-ID: <9front.9front.org> List-Help: X-Glyph: ➈ X-Bullshit: anonymous ISO-certified TOR over SQL standard STM map/reduce frontend Subject: [9front] The great experimental file shredder Reply-To: 9front@9front.org Precedence: bulk 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!