I doubt that 5 years from now the norm for *desktops* will be 12 disks on a RAID and 8 threads writing on it.
I think <8 threads writing concurrently is going to be the normal case for desktop systems for quite a while, and I'm not sure any amount of hand-waving is going to dismiss XFS being 50% slower compared to ext4 in your benchmarks in the case that is important to desktop users.
No, 3 seconds compared to 2 seconds doesn't sound so bad, but I'd expect that to mean also that the operations that now take 2 minutes on my ext4 to take 3 minutes on XFS. A 50% difference certainly means it is appreciably slower.
Simply put, I don't think scalability in the way it is exercised in your tests is relevant to desktop users currently or in the near future. More than 8 threads may be imaginable in the future, but 12 disks is not. At least currently I care way more about a single-threaded workload being much slower on XFS (per your benchmarks). It *is* the absolute numbers that matter, after all.
Posted Jan 26, 2012 20:33 UTC (Thu) by dlang (✭ supporter ✭, #313)
[Link]
today most SSD drives internally act as if they are a raid set, so saying that in 5 years that RAID will be a common desktop/laptop feature is actually a fair statement.
as for multiple thread writing to it, that's more common than you think as well (media player streaming, desktop environment saving state, word processor saving state, spreadsheet saving state, .... )
XFS: the filesystem of the future?
Posted Jan 28, 2012 2:48 UTC (Sat) by sbergman27 (guest, #10767)
[Link]
"today most SSD drives internally act as if they are a raid set"
Maybe. But SSD drives act, externally, as 1 drive. A single drive with excellent seek time and a sometimes very good data rate. If the drive can do parallelization of a single stream of data that means the FS and block i/o layers don't have to be so fancy. +1 for EXT4.
Regarding multiple threads writing... do you really think media player streaming and word processor saving state is going to require a half gig a second via 5+ threads for extended periods in the near future? If so, I think I'll go dust off my TV and typewriter. +1 for Magnavox and Royal.
XFS: the filesystem of the future?
Posted Jan 27, 2012 0:50 UTC (Fri) by dgc (subscriber, #6611)
[Link]
> I doubt that 5 years from now the norm for *desktops* will be 12 disks
> on a RAID and 8 threads writing on it.
That device used RAID to get the capacity over 16TB, and 512MB of BBWC to keep the IOPS and bandwidth high to/from spinning disk storage. It sustained up to 10,000 IOPS and 600MB/s on some of those workloads. That's the only reason RAID was used.
To put that IO capability in context, my desktop already has 8 processor threads and a pair of SSDs that sustain 70,000 random write IOPS and 500MB/s. That cost me about $1500 a couple of years ago. It has more capability from the IO perspective than the hardware that I ran the tests on (except for capacity). And I do 8-way kernel builds on it, so I'm already writing with 8 threads to the filesystem on my desktop machine.
IOWs, the test system and tests I described are relevant not only to people with current low end servers but also relevant to those with current medium-to-high-end desktops and laptops. As I've said previously, that was the whole point of the exercise - to show how capable cheap, low end storage is these days and how only XFS can make full use of it....
> Now, 3 seconds compared to 2 seconds doesn't sound so bad, but I'd expect
> that to mean also that the operations that now take 2 minutes on my
> ext4 to take 3 minutes on XFS. A 50% difference certainly means it is
> appreciably slower.
You simply can't make that sort of generic extrapolation from one workload to all workloads. Because the main tests I ran reflected one -specific- aspect of metadata workloads (creates in isolation, read in isolation, unlink in isolation) you can use those numbers to get an idea of how a workload that is heavy in those behaviours might perform and scale. But you cannot say that all workloads will end up with a specific performance differential just because one workload had that differential...