Re: [PATCH v6 5/5] btrfs: introduce new read_policy device

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

 




Whenever there isn't any read preferred device(s) or if more than one
stripe is marked as read preferred device then this read policy shall
use the stripe 0 for reading.

Should we consider the situation where more than one device is preferred (perhaps for a future patch) - e.g. devid1 is HDD, devid2 is SSD, devid3 is SSD and data is RAID1C3?

Once we have read policy type qdepth, we will use the read preferred device with the larger qdepth. This message is in the code comment. Oops I should have add it here also.

Will there be a warning when this fallback to stripe 0 happens? Although I imagine that would either always display on mount before read_preferred is set or flood dmesg for every read.

In a 3 disks raid1, if there is only one disk marked as read preferred, and if the stripe 0 and 1 are on non-read-preferred disks, it will pick stripe 0 and warning is unnecessary.

In a 3 disks raid1, if there are 2 disks marked as read preferred, and the stripe 0 and 1 are on those two read preferred disks, we will be using the Qdepth to find the suitable read preferred device.

Perhaps fallback to the %pid policy to give some form of balancing would be a better default?


Lets say read_policy is set to 'device' but there isn't any read_preferred device, then it make sense to fall back to default read_policy. But for every read to determine if there is any read preferred device outside of the striped chunk not a good idea.

Thanks, Anand



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

  Powered by Linux