On Sat, Apr 09, 2016 at 12:40:18AM +0300, Yuriy M. Kaminskiy wrote:
> I think this algorithm should work:
>
> 1) walk /dev/block/${dev}/slaves recursively (e.g. lvm-over- luks-
> over-lvm- over-md, first-level slaves won't work), collect all
> whole-disk devices;
> 2) sort this list by device numbers (to avoid AB/BA deadlocks), remove
> duplicates;
> 3) acquire all locks consequently.
>
> There are some unavoidable flaws (e.g. if someone alters structure while fsck
> is running), and some things could be improved, but it should work in
> most cases (and if it fails, it is just no worse than current behavior).
>
> I've tested with LVM and LUKS-over-LVM on (debian's) 3.16 kernel, it seems
> works as expected.
>
> What is not covered: /dev/loop* (and I have no plans for it).
>
> Comments? NACKs?
The question is if we really need it :-)
All the care fsck has about whole-disks is about performance, because
we assume (on classic rotation disks) that execute fsck on more
partitions in the same time is bad idea.
The problem with stacked devices is that we have no clue about sectors
mapping. Your patch locks all the disks, but maybe kernel will read
only from some subset of the disks, etc.
>From my point of view the best way is not to care about it in
userspace at all and depend on kernel I/O scheduling only. The
optimization probably still makes sense for classic layout
"HDD->partition", but I don't think we need to extend this
functionality to another use-cases.
Karel
--
Karel Zak <kzak@xxxxxxxxxx>
http://karelzak.blogspot.com
--
To unsubscribe from this list: send the line "unsubscribe util-linux" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
