Re: XFS: Abysmal write performance because of excessive seeking (allocation groups to blame?)

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



> try 128k to 512k for stripe size.  And try to increase your agcount by
> (nearly) an order of magnitude.

Would that be of any real value to anyone here, except for satisfying
curiosity (which I feel as well ;))? Because frankly, it’s a lot of
work, and I’m quite through with this tedious kind of activity…

My conclusion is that everything should work well if the levels below
the file system behaved the way they should and brought the writes
into a sane order. Apparently, both the RAID controller as well as the
Linux block scheduler fail to do so. Despite the annoying nature of
this state of affairs, I do believe that file systems should be able
to count on the lower levels of the stack for such low-level work and
not work around them, but apparently, they are often failed. Probably
that’s one of the reasons why almost every file system acquires some
sort of block scheduling over time. Maybe some day, the Linux IO
scheduler will do a better job. Unfortunately, by then, this entire
issue will be irrelevant because nobody will be using rotational
storage anymore, at least not for everyday work.

_______________________________________________
xfs mailing list
xfs@xxxxxxxxxxx
http://oss.sgi.com/mailman/listinfo/xfs



[Index of Archives]     [Linux XFS Devel]     [Linux Filesystem Development]     [Filesystem Testing]     [Linux USB Devel]     [Linux Audio Users]     [Yosemite News]     [Linux Kernel]     [Linux SCSI]

  Powered by Linux