Re: UFS and ext2
On Fri, 28 Apr 2000, Larry McVoy wrote: > On Sat, Apr 29, 2000 at 11:37:34AM +0900, GOTO Masanori wrote: > > I don't know quantitative comparison between FreeBSD FFS > > and Ext2. However, both FFS and ext2 have similar > > structures, so I guess both performance are nice... > > UFS is a lot slower than ext2 because ext2 does async meta data updates. This > has been the cause of much discussion, with the UFS crowd (I'm one of them, > I doubled UFS performance at Sun) claiming that because UFS is "safe" and > ext2 is "unsafe". That claim is where I part ways with the UFS crowd, I've > been using ext2 for years, have survived many crashes, and I don't see any > difference in the frequency of fsck problems. > > And the difference in performance is HUGE. A file create in UFS is about > 12,000 usecs. A create in in ext2 is about 100 usecs. Larry, that's only a part of the story. First of all, UFS on Linux is async by default, just as ext2. So speed is about the same. Said that, Linux UFS driver is, IMO, less reliable than ext2 one. And on FreeBSD... You have to compare not sync/async, but soft-updates/async. And there the difference is nowhere near 120:1... I would not trust ext2 driver in FreeBSD too much - it's based on the old code and we had found data-corrupting races on our side since then. And it's not too actively maintained.
Re: UFS and ext2
On Sat, Apr 29, 2000 at 11:37:34AM +0900, GOTO Masanori wrote: > I don't know quantitative comparison between FreeBSD FFS > and Ext2. However, both FFS and ext2 have similar > structures, so I guess both performance are nice... UFS is a lot slower than ext2 because ext2 does async meta data updates. This has been the cause of much discussion, with the UFS crowd (I'm one of them, I doubled UFS performance at Sun) claiming that because UFS is "safe" and ext2 is "unsafe". That claim is where I part ways with the UFS crowd, I've been using ext2 for years, have survived many crashes, and I don't see any difference in the frequency of fsck problems. And the difference in performance is HUGE. A file create in UFS is about 12,000 usecs. A create in in ext2 is about 100 usecs. -- --- Larry McVoy[EMAIL PROTECTED] http://www.bitmover.com/lm
Re: UFS and ext2
I don't know quantitative comparison between FreeBSD FFS and Ext2. However, both FFS and ext2 have similar structures, so I guess both performance are nice... Regards, -- GOTO Masanori From: warren <[EMAIL PROTECTED]> Subject: UFS and ext2 > I try to setup a file server using Linux ext2 or FreeBSD ufs. Which > one has better performance? Where i can find more information about > their features and comparison?
UFS and ext2
Hi, I try to setup a file server using Linux ext2 or FreeBSD ufs. Which one has better performance? Where i can find more information about their features and comparison? Warren
Re: ext2 feature request
On Fri, 28 Apr 2000, Andrew Clausen wrote: > Hi all, > > Is it possible to have a gap between the super-block and the > start of group 0's metadata? This would be REALLY useful, for: Yes, but... [snip] > the first block on the old partition is now the 50.25th block > in the new one. Obviously, you can't reference block 50.25 > in, say, an inode! The block would have to be moved, to say > block 50. Therefore, a resize would involve (AT LEAST) reading > in everything, and writing it back again at a different spot. ... _that_ (offset being not a multiple of block size) would require changes in fs/buffer.c and drivers/block/ll_rw_blk.c and frankly, I don't see the point - extra overhead for everyone, and what for?
ext2 feature request
Hi all, Is it possible to have a gap between the super-block and the start of group 0's metadata? This would be REALLY useful, for: * giving boot loaders a nice fixed place to store data. * allowing partition resizers to align blocks, when resizing the start of ext2 partitions. To illustrate: imagine you have a block size of 4k. You move (i.e. grow) the start of the partition back, say, 201k (you don't get to choose the granularity, because of M$ partition alignment rules). Then the first block on the old partition is now the 50.25th block in the new one. Obviously, you can't reference block 50.25 in, say, an inode! The block would have to be moved, to say block 50. Therefore, a resize would involve (AT LEAST) reading in everything, and writing it back again at a different spot. Having a gap between the superblock and the start of the rest of the fs would allow us to keep all the blocks aligned properly, during a resize. Thanks! Andrew Clausen
