Date: Sun, 8 Jul 2001 15:43:23 +0200 From: "Karsten W. Rohrbach" <karsten@rohrbach.de> To: Greg Lehey <grog@FreeBSD.org> Cc: "A. L. Meyers" <a.l.meyers@consult-meyers.com>, Antony T Curtis <antony@abacus.co.uk>, freebsd-stable@FreeBSD.ORG Subject: Re: ReiserFS (was: JFS (was: The FreeBSD core team needs your help)) Message-ID: <20010708154323.E24461@mail.webmonster.de> In-Reply-To: <20010708090243.U75626@wantadilla.lemis.com>; from grog@FreeBSD.org on Sun, Jul 08, 2001 at 09:02:43AM %2B0930 References: <20010707132458.D75626@wantadilla.lemis.com> <20010707144259.Q550-100000@consult-meyers.com> <20010708090243.U75626@wantadilla.lemis.com>
next in thread | previous in thread | raw e-mail | index | archive | help
[-- Attachment #1 --] Greg Lehey(grog@FreeBSD.org)@2001.07.08 09:02:43 +0000: [...] > > Just installed SuSE Linux 7.2 with Reiser FS throughout on an Intel > > SMP box. The FS purrs, even on /, which doesn't mean everything is > > better or worse than FBSD. > > I don't know enough about ReiserFS to be able to give a useful > opinion. The Linux people I know are by no means in agreement about > its merits, but I've heard that it's best as a "special purpose" FS > for small files. I don't know how valid that statement is. reiserfs has several features/benefits compared to ufs based filesystems but it also breaks common semantics, especially in fsync()'s behaviour. first of all, the base filesystem layer for payload data operates on a linear namespace. this layer gets the hierarchical mapping and metadata layer ontop which gives you a standard hierarchical fs structure. the metadata is organized in a hash which makes file access much faster, especially in directories containing many files. then there is tail optimization which puts more than one file in one block on the disk -- file payload does not have to start at a block boundary -- this is more efficient, but time consuming (degrades fs performance, opposed to mountopt notail which runs at full speed then). the base fs is log structured, AFAIK. the only problem that i experienced is fsync()'s strangeness since it returns immediately, not ensuring that the data was actually written physically, but this might be fixed now... there is also resizing on the fly (basically remounting with the new fs size as mountopt) which seems to include journal relocation, this is new to me. reiserfs also has no hard limit for the max number of inodes at mkfs time. please correct me if got something wrong. the papers can be found at http://www.namesys.com/ /k -- > Parts that don't exist can't break. --Russell Nelson KR433/KR11-RIPE -- WebMonster Community Founder -- nGENn GmbH Senior Techie http://www.webmonster.de/ -- ftp://ftp.webmonster.de/ -- http://www.ngenn.net/ karsten&rohrbach.de -- alpha&ngenn.net -- alpha&scene.org -- catch@spam.de GnuPG 0x2964BF46 2001-03-15 42F9 9FFF 50D4 2F38 DBEE DF22 3340 4F4E 2964 BF46 Please do not remove my address from To: and Cc: fields in mailing lists. 10x [-- Attachment #2 --] -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.0.6 (FreeBSD) Comment: For info see http://www.gnupg.org iD8DBQE7SGN7M0BPTilkv0YRAkcUAJ9GvZgTrv5oxgWbwKKHhMAGpuOOPgCfY8Hg QrtGNINrwPgPxZPF9o3dXh0= =vgCn -----END PGP SIGNATURE-----
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20010708154323.E24461>