> > And 'maybe' for adaptive RA just increase the RA-blocks by '1'(or some N) over period of time. No more smartness. A simple 10 line function is > > easy to debug/maintain. That is, a scaled-down version of ramp-up/ramp-down. Don't go crazy by ramping-up/down after every RA(like > > SCSI LLDD madness). Wait for some event to happen. > > Doing 1-block readahead increments is a performance disaster on RAID- > 5/6. That means you seek all the disks, but use only a fraction of the > data that the controller read internally and had to parity check. > > It makes more sense to keep the read units the same size as write units > (1 MB or as dictated by RAID geometry) that the filesystem is also > hopefully using for allocation. When doing a readahead it should fetch > the whole chunk at one time, then not do another until it needs another > full chunk. > I was using it loosely(don't confuse it with 1 block as in 4K :). RA could be tied to whatever appropriate parameters depending on the setup(underlying backing store) etc. But the point I'm trying to make is to (may be)keep the adaptive logic simple. So if you start with RA-chunk == 512KB/xMB, then when we increment it, do something like (RA-chunk << N). BTW, it's not just RAID but also different abstractions you might have. Stripe-width worth of RA is still useless if your LVM chunk is N * stripe-width. > Cheers, Andreas Chetan -- To unsubscribe from this list: send the line "unsubscribe linux-fsdevel" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
