On 26/01/15 13:21, Karel Zak wrote: > On Mon, Jan 26, 2015 at 10:36:02AM +0100, Daniel Pocock wrote: >> On 26/01/15 10:32, Karel Zak wrote: >>> On Mon, Jan 26, 2015 at 02:24:04AM +0100, Michael Biebl wrote: >>>>> -l Create an exclusive flock(2) lock file >>>>> (/run/fsck/<diskname>.lock) for whole-disk >>>>> device. This option can be used with one device only (this >>>>> means that -A and -l are >>>>> mutually exclusive). This option is recommended when >>>>> more fsck(8) instances are exe- >>>>> cuted in the same time. The option is ignored when used >>>>> for multiple devices or for >>>>> non-rotating disks. fsck does not lock underlying >>>>> devices when executed to check >>>>> stacked devices (e.g. MD or DM) - this feature is not >>>>> implemented yet. >>>> Karel, is there an upstream bug report for this issue? What's the state >>>> of this feature, is it actively being worked on? >>> No, nobody is workning on -l for stacked devices. >>> >>> Karel >>> >> Is there any other workaround, or should people consider moving to BtrFs >> instead of using LVM on md? > fsck has never been able to determine all the stack, so this is no change > (change between "fsck -l" from systemd and "fsck -A" from init scripts). > > All the problem is possible negative impact to performance if you want > to intensively use two partitions on the same hdd, that's all. The > question is if this is really issue in all cases for all HW. > > > Frankly, I'm pretty unhappy that we care about such things in > userspace -- it's kernel job to schedule things and keep system > performance "usable", all we can do in userspace is to inform > kernel about the way how we plan to use the devices (e.g. fadvise()). > > The stack of the block devices maybe pretty complicated and only DM/MD > kernel drivers have a clue where are things really stored. The another > story is that sometimes nothing include kernel has a clue about HW, > because storage maybe completely independent invisible blackbox (SAN, etc.). > > My recommendation is to ignore this issue, or if you really see any > performance problem than disable fsck by systemd and use by hands > written script to call fsck.
I agree it is not a trivial thing to fix due to all the possible permutations of storage infrastructure, that is why I was asking if there is any workaround The performance impact is not trivial. I have 28 LVs on my main /dev/md and 47 on an external disk that is used to replicate other filesystems. Both of these disks make a horrible thrashing sound while fsck runs. I'm really thinking about moving a lot of these to BtrFs subvolumes and that appears to be a valid solution. One partial solution that may be easy to implement in fsck would be to serialize by volume group. So if it is asked to scan /dev/mapper/vg00-root and /var/mapper/vg00-var at the same time then it can see they are both on vg00 and let one finish before the other starts. I realize that being on the same VG doesn't imply the same physical spindle, that is why I call this a partial solution, but this probably works for a lot of users on small systems who don't want to think about more elaborate solutions. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
