From mboxrd@z Thu Jan  1 00:00:00 1970
Return-Path: <9front-bounces@9front.inri.net>
X-Spam-Checker-Version: SpamAssassin 3.4.4 (2020-01-24) on inbox.vuxu.org
X-Spam-Level: 
X-Spam-Status: No, score=-0.6 required=5.0 tests=DKIM_INVALID,DKIM_SIGNED,
	HEADER_FROM_DIFFERENT_DOMAINS,MAILING_LIST_MULTI autolearn=ham
	autolearn_force=no version=3.4.4
Received: from 9front.inri.net (9front.inri.net [168.235.81.73])
	by inbox.vuxu.org (Postfix) with ESMTP id 29E3424A5E
	for <ml@inbox.vuxu.org>; Mon,  6 May 2024 18:07:03 +0200 (CEST)
Received: from wopr.sciops.net ([216.126.196.60]) by 9front; Mon May  6 12:04:01 -0400 2024
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=sciops.net; s=20210706;
	t=1715011394;
	h=from:from:reply-to:subject:subject:date:date:message-id:message-id:
	 to:to:cc:mime-version:mime-version:content-type:content-type:
	 content-transfer-encoding:content-transfer-encoding:  in-reply-to:in-reply-to;
	bh=GUKIyIzO7IiLGw0sFuaR9/k/oYeHZfF2qL3zYvenSY4=;
	b=lxhnVipaST0Jjx+P/ev1wm+scgWbhWoNJIXmvc8h5r1pTMt20tHkaAc5f8HQkgDZsYl8TE
	EnUVXivlPpsbhBHKKoZUryADtJDWya2hu3lfHGEKn/j7C9hKHzWvlNBOAzADVgtHhe00iL
	Je8VbfHut64wqV/iebqWL6pKhtaYZqM=
Received: 
	by wopr.sciops.net (OpenSMTPD) with ESMTPSA id 4a19e955 (TLSv1.2:ECDHE-RSA-CHACHA20-POLY1305:256:NO)
	for <9front@9front.org>;
	Mon, 6 May 2024 09:03:13 -0700 (PDT)
Message-ID: <974B46A300B9BE8F5D3A5DFEA23C2FBD@wopr.sciops.net>
Date: Mon, 06 May 2024 18:03:36 +0200
From: qwx@sciops.net
To: 9front@9front.org
In-Reply-To: <73EDEC59-DF58-4D74-A2C8-B2090C47F579@stanleylieber.com>
MIME-Version: 1.0
Content-Type: text/plain; charset="US-ASCII"
Content-Transfer-Encoding: 7bit
List-ID: <9front.9front.org>
List-Help: <http://lists.9front.org>
X-Glyph: ➈
X-Bullshit: secure configuration service AJAX over JSON event reduce/map manager 
Subject: Re: [9front] AUTHENTICATE failed can't get challenge (imap4d)
Reply-To: 9front@9front.org
Precedence: bulk

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