Date: Fri, 21 Sep 2007 14:45:35 +0200 From: Ivan Voras <ivoras@freebsd.org> To: freebsd-fs@freebsd.org Subject: Re: Writing contigiously to UFS2? Message-ID: <fd0edf$7jd$1@sea.gmane.org> In-Reply-To: <46F3B520.1070708@FreeBSD.org> References: <46F3A64C.4090507@fluffles.net> <fd0aaj$poh$1@sea.gmane.org> <46F3B520.1070708@FreeBSD.org>
next in thread | previous in thread | raw e-mail | index | archive | help
This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --------------enigE36410BE42DF53D7D8D7BB25 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: quoted-printable Stefan Esser wrote: > Ivan Voras wrote: >> (ZFS is not the ultimate solution: 1) replacing UFS monoculture with Z= FS >> monoculture will sooner or later yield problems, and 2) sometimes a >> "dumb" unix filesystem is preferred to the "smart" ZFS). >=20 > Both XFS and ReiserFS are quite complex compared to UFS definitely > not well described by the term "dumb" ;-) Of course, I mean no disrespect to them, I've read enough papers on them = to realize their complexity :) By "dumb" I meant they behave like "point = them to a device and they will stick to it", i.e. they don't come with a = volume manager. > The FFS paper by McKusick et.al describes the historical allocation > strategy, which was somewhat modified in FreeBSD a few years ago in > order to adapt to modern disk sizes (larger cylinder groups, meaning > it is not a good idea to create each new directory in a new cylinder > group). [thinking out loud:] From experience (not from reading code or the docs) I conclude that=20 cylinder groups cannot be larger than around 190 MB. I know this from=20 numerous runnings of newfs and during development of gvirstor which=20 interacts with cg in an "interesting" way. I know the reasons why cgs=20 exist (mainly to lower latencies from seeking) but with todays drives=20 and memory configurations it would sometimes be nice to make them larger = or in the extreme, make just one cg that covers the entire drive.=20 Though, this extreme would in case of concat configurations put all of=20 block and inode metadata on the first drive which could have interesting = effects on performance. Of course, with seek-less drives (solid state)=20 there's no reason to have cgs at all. --------------enigE36410BE42DF53D7D8D7BB25 Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.5 (GNU/Linux) Comment: Using GnuPG with SUSE - http://enigmail.mozdev.org iD8DBQFG87zvldnAQVacBcgRA+QDAJ9DAe3v2ddR9WZRzx/KlKjBye0erACfYHMg VoW1ozr75Mbml3V8oN0Sw3M= =DEqb -----END PGP SIGNATURE----- --------------enigE36410BE42DF53D7D8D7BB25--
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?fd0edf$7jd$1>