Date: Tue, 2 Jun 1998 23:47:15 +0200 From: Ollivier Robert <roberto@eurocontrol.fr> To: freebsd-fs@FreeBSD.ORG Subject: Fwd: Re: ext2fs and the qmail list... Message-ID: <19980602234715.B1717@caerdonn.eurocontrol.fr>
next in thread | raw e-mail | index | archive | help
Just found this on a mailing-list. Anyone's heard about this journaled Ext2 ? ----- Forwarded message from Sean Reifschneider <jafo@tummy.com> ----- Date: Tue, 2 Jun 1998 15:24:26 -0600 From: Sean Reifschneider <jafo@tummy.com> Subject: Re: ext2fs and the qmail list... On Sat, May 23, 1998 at 07:20:11PM -0400, Wietse Venema wrote: >In addition to running performance measurements on *BSD I also ran >them on LINUX, and found that LINUX was a bit too fast to be true. As I understand it, BSD variants will essentially sync the metadata after every operation (create, write, and remove). With Linux, it will only sync when you tell it to or it decides it's time. Linux is updating all the blocks for the previous remove, create, and writes when you call the fsync. Since the file-system tries to keep things close to eachother, it's not necessarily cheating... I don't know for sure that Linux does actually sync the data when you do an fsync, but I'd be suprised if they didn't. However, if they were *REALLY* cheating, why's it so slow? I ran it on my machine with "-c 10000" in 10.26 seconds -- 1.03ms per file. That's more the speed I'd be expecting if they were REALLY cheating. My numbers are so fast because I have my controller set up to ACK the write as soon as the data is deposited on the controller's cache. I just got back from Linux Expo, and one of the presentations was from Stephen Tweedie about Journaling EXT2. It sounds like the design is completed (and *VERY* well thought-out) and they are working on the implementation. They are claiming that they'll probably see increased performance as well as rock-solid reliability. >Someone observed that non-volatile cache (Prestoserve) can really >speed things up by a lot more than a factor of 2 because the disk >driver can sort writes into the most efficient order. Apparently Linux already does a fairly good job of that already. I have asked around and especially with todays more intelligent discs, elevator sorting is much less an issue than it used to be. I have noticed that ACKing the sync when data is written to the controller cache instead of to the discs can make a HUGE difference. With UPSs or things like the Mylex RAID boards (with optional NVRAM) it can be done reliably as well. >I wouldn't use LINUX for mission-critial applications. That seems a bit heavy-handed... Especially when Linux has just chosen async as the default. If you run it on a mission-critical server, add the "sync" option. On my notebook I ran your test program and it took roughly 3 seconds for 100 files with the fs mounted async, and 16 seconds with it mounted sync. Since it takes twice as long as your BSD/OS box, it must be *REALLY* good. :-) Sean -- Tools may limit the user, but the utility of tools is limited by the skill of the user. -- Leonard Compagno Sean Reifschneider, Inimitably Superfluous <jafo@tummy.com> URL: <http://www.tummy.com/xvscan>; HP-UX/Linux/FreeBSD/BSDOS scanning software. ----- End forwarded message ----- -- Ollivier ROBERT -=- Eurocontrol EEC/TS -=- Ollivier.Robert@eurocontrol.fr FreeBSD caerdonn.eurocontrol.fr 3.0-CURRENT #5: Tue Apr 22 14:57:00 CEST 1997 roberto@caerdonn.eurocontrol.fr:/src/src/sys/compile/CAERDONN2 i386 To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-fs" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?19980602234715.B1717>