Date: Tue, 1 Nov 2005 12:06:42 +0100 (CET) From: Ivan Voras <ivoras@fer.hr> To: Bruce Evans <bde@zeta.org.au> Cc: freebsd-fs@freebsd.org Subject: Re: ext2 large_file Message-ID: <20051101114150.X90580@geri.cc.fer.hr> In-Reply-To: <20051101141726.W41623@delplex.bde.org> References: <20051030183340.B19470@geri.cc.fer.hr> <46D894BD-16E0-4CBA-B40A-EEBAAC2547D2@classicalguitar.net> <20051031191139.J38757@delplex.bde.org> <20051031160354.G67271@geri.cc.fer.hr> <20051101042444.K40281@delplex.bde.org> <20051031201719.S68800@geri.cc.fer.hr> <20051101141726.W41623@delplex.bde.org>
next in thread | previous in thread | raw e-mail | index | archive | help
On Tue, 1 Nov 2005, Bruce Evans wrote: > On Mon, 31 Oct 2005, Ivan Voras wrote: >> I did this but e2fsck doesn't set the flag. Fortunately, I found out that >> e2fsprogs includes "debugfs" utility with which I manually set the flag. > > Does e2fsck report the problem? Surprisingly, no. It run normally (as far as I can tell) without reporting anything. This was on an unmounted system that contained one large (3GB) file created (actually extended from a 2G file) in the Windows ext2 driver, which also didn't set the flag (though its documentation said it would). Maybe there's undocumented "features" regarding extending already existing files. > Strangely enough, I first got interested in ext2fs under FreeBSD because > testing showed that it was faster than ffs in one configuration, and this > turned out to be mostly because of fragmentation: Very nice explanation, thanks! > - ext2fs under FreeBSD has a primitive block allocator that will give lots > and never delete files, the layout is almost optimal. In particular, > the layout is good after copying a large directory tree to a new file This is what I was doing with msdosfs, and accidentally looked at the defragmenter - the display was like it's been randomly fragmented. Now I know why :) > first few cylinder groups full and the rest unused, where Linux would > use all the groups fairly evenly. Not so good. I suppose this is not easaly fixable? > - soft updates (in this test) is now not much faster than ordinary > (-nosync -noasync) mounts and is much slower than async mounts. It > used to be only 1.5 times slower than async mounts. This test was I've noticed this too. > - ext2fs is about twice as slow as the other 2 (worse for non-async writes). > It is mostly because the block size is very small, and although this > only necessarily costs extra CPU to do clustering, FreeBSD is optimized > for ffs's default block size and does pessimal things with ext2fs's > smaller sizes. These effects are also very noticable with NTFS (default block size=4096 for all/most partition sizes) and FAT32 on smaller drives (where bs=4096 fits FAT in 8MB).
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20051101114150.X90580>