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.
Karel
--
Karel Zak <k...@redhat.com>
http://karelzak.blogspot.com
--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
