> > OK, now to the crux of the matter, these mkfs options are not going to
> > you achieve higher bandwidth, your hardware is going to play the biggest
> > in this, so it is all really a matter of budget.
> I do agree that hardware plays a big part, but really software plays just a
> big a part in the system.
> For instance, I discovered that my performance increased by a factor of
> three on a RAID 5 system when I increased the block size from 1K to 4K. That
> to me means that I did not have to spend money on getting drives which were
> three times faster then the ones I already had (considering the ones I had
> were 15000 rpm that was going to be hard ;).
I guess my point here was that since xfs is currently making filesystems
with a 4K block size, there is not a lot you can do with mkfs options to
get better throughput right now.
> Is there a time frame when these these extra features will be added?
We are working on support for blocks smaller than a page - this will be
needed for other platforms (ia64 being a prime example internally at SGI)
where the hardware wants to use a larger page size, but we want to keep
the filesystem blocksize down. This should not be many weeks, but does
not help you. Support for block size larger than a page is not going to
happen anytime soon - probably at least a 2.5 thing, and given how
the linux kernel organizes memory it is probably not going to be am
easy performance win.
Completion of the realtime subvolume support is also in the works, this will
allow I/O to the realtime device (direct I/O only). This will behave
differently since the realtime subvolume does not have any bounds on its
extent size, and since there is nothing on the volume but file data,
you should be able to get at least more consistent I/O to and from it.
Note that realtime is a misnomer here, other components of xfs for I/O
scheduling are much further down the pipeline.
> BTW: I love the product, keep up the great work.