Messages in this thread | | | Subject | Re: [OT] SGI to OpenSource XFS | Date | Mon, 24 May 1999 11:32:53 -0600 | From | Larry McVoy <> |
| |
: XFS has some nice features such as journalling, dynamically managed inodes, : B-tree directories, and real-time features for multimedia streams (looks like : this last one will not be in the open-sourced code). : But how about performance ? Does anybody have comparisons of various : filesystems in terms of performance ?
I know a lot about XFS performance. Unfortunately, it's hard to split out what parts are XFS and what parts are IRIX infrastructure.
Some parts of XFS are amazing (actually, it isn't XFS that's so fast, it's XLV - the volume manager underneath - XFS does its part by getting out of the way and letting XLV set up all the DMAs in parallel). The I/O bandwidth that you can get out of XFS/XLV is limited only by the hardware. When I was at SGI they demoed XFS doing 7GByte/second and there is no reason why that number couldn't be 7TByte/second.
The journalling is nice - it's nowhere near as fast as ext2 but it is safe, you can turn off the machine the middle of an untar and things are in a sane state when you reboot. I strongly suspect that Stephen's journalling work will be lighter weight.
XFS is extent based so you could have a 10TB file that was made up of a small number of extents, very nice.
I suspect that what will happen is that we'll get XFS, take a while to understand it and then migrate the ideas that we want into ext3 or whatever Stephen is calling his thing. For a lot of stuff, XFS is overkill and it comes at a non-zero cost.
- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.rutgers.edu Please read the FAQ at http://www.tux.org/lkml/
| |