Re: [9front] AUTHENTICATE failed can't get challenge (imap4d)

[qwx@sciops.net]

On Mon May  6 17:42:29 +0200 2024, sl@stanleylieber.com wrote:
> for over ten years, i have been running 9front associated mailing lists, websites, etc., in virtual machines hosted at a series of different places. in that time, i have tried all kinds of different setups, including:
> 
> - hjfs, dump only triggered manually: 1k blocks, all on one partition, corruption can be surgically addressed if you're a disk doctor, gets very slow when a large partition passes half full
> 
> - cwfs, dump mandatory and automatic: 4k blocks, multiple partitions, very easy to fill cache or worm, corruption relatively easy to address
> 
> - cwfs, no dump: 4k blocks, all on one partition, corruption harder to address
> 
> in the context of managing the sites, corruption has never been a significant source of pain, even with lots of unclean shutdowns. my biggest problem (by far) with disks has been babysitting the cache/worm. moving lots of files onto the system means shoveling bits carefully into the cache until it's not quite full and then doing a dump to clean it out before proceeding. when corruption happens, i move the corrupted file out of the way and move on. when the worm fills up, you're fucked,  full stop.
> 
> all our disk file servers are vulnerable to unclean shutdowns. hjfs is good for constrained disk space because 1k blocks and everything being on one partition means no babysitting the cache/worm. cwfs is good for actually being a file system because it's fast. but, depending on your setup, dealing with the cache is a huge pain. on a system with a huge number of files, many of which are changing all the time, and all of which need to be available and readily accessible, the way cwfs' cache works and is proportioned is a nightmare.
> 
> in retrospect it's obvious the most advantageous setup would be to retain the worm for system files, and create a separate, non-worm partition for the huge number of files, many of which are changing all the time, and all of which need to be available and readily accessible.
> 
> i will now travel back in time and give myself this advice. 
> 
> sl

Thanks for taking the time to describe your experience in detail.
There's no ideal solution (yet!).  I've personally had more trouble
with corruption and gave up on the no-dump configuration because of
it.  Filling up the cache by accident and similar are not too easy to
avoid and worm management can also be really frustrating as you said.

imho your mail should be added to the fqa, even as is, since there's
little public information on how to choose a filesystem and especially
what the trade-offs or maintenance burdens are in the longer term,
where exactly performance suffers, etc.

Cheers,
qwx