Date: Wed, 27 May 1998 09:49:56 +0200 From: Martin Cracauer <cracauer@cons.org> To: Amancio Hasty <hasty@rah.star-gate.com>, Martin Cracauer <cracauer@cons.org> Cc: Ted Stein <ted@taki.net>, advocacy@FreeBSD.ORG Subject: Re: Braindead FreeBSD advocates (Re: Advocacy Shortcomings) Message-ID: <19980527094956.00484@cons.org> In-Reply-To: <199805261556.IAA04155@rah.star-gate.com>; from Amancio Hasty on Tue, May 26, 1998 at 08:56:39AM -0700 References: <19980526121304.51425@cons.org> <199805261556.IAA04155@rah.star-gate.com>
next in thread | previous in thread | raw e-mail | index | archive | help
In <199805261556.IAA04155@rah.star-gate.com>, Amancio Hasty wrote: > The debate at slasdot.org was fine . The FreeBSD advocacy was not > brilliant however the linux advocay was even worse. Well, from a certain standpoint the FreeBSD votes may have been reasonable in that their fought the Linux folks with their own weapons (at least the weapons they use in non-linux dominated forums). However, I think the FreeBSD folks have to do better as they fight from an inferior position. Unreasonable FreeBSD advocacy hurts more than unreasonable Linux advocacy. > The next time an article gets published at slashdot.org just try > to follow up with a few good posts. Tried to do so. > With respect to advocates, basically, the group needs to come up with a > few good themes or stories which can be backed up with data. One thing I'd really like is a down-to-metal explanation of the (a)sync metadata issue. Describe exactly under what circumstances the typical Linux filesystem is in a state that will loose files or the whole filesystem. Theo De Raadt came up with a good example: A simple rename(2)/mv(1) is usualy thought to be an operation that can't lose the file. Not so on Linux. Explanation in my (half-baken) words: Since metadata is async and writes are completely unsorted, about half of the rename operations have an intermediate state where the old filename is deleted but the new one isn't in place. Since Linux also doesn't have any contraints about the chunks written out, allocatition and connection of the new name may also happen an arbitrary long time after loosing the old name. If your system crashes within that time, you still have the data blocks and the indoe, but you'll the data unnamed in lost+found. The latter also concerns the quality of Linux fsck, which I'm not sure about, maybe the file gets lost completely. I'm not sure I understand enough of the issue to make a bullet-proof webpage with some diagrams. This requires reading quite a lot of Linux kernel/fsck/mkext2fs code. For FreeBSD, I also noted that the comments in the 4.4BSD book about metadata synchronisation don't meet reality in FreeBSD. Martin -- %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% Martin Cracauer <cracauer@cons.org> http://www.cons.org/cracauer BSD User Group Hamburg, Germany http://www.bsdhh.org/ To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-advocacy" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?19980527094956.00484>