Debian Bug report logs - #776034
fsck: implement support for stacked devices (MD/DM/RAID)

Reply or subscribe to this bug.

Toggle useless messages

Message #5 received at submit@bugs.debian.org (full text, mbox, reply):

From: Daniel Pocock <daniel@pocock.pro>

To: submit@bugs.debian.org

Subject: fsck runs in parallel on same physical disk

Date: Fri, 23 Jan 2015 07:44:57 +0100

Package: systemd
Version: 215-8
Severity: serious


I have a server with many LVM logical volumes on top of the same RAID1
md device on two spindles.

At boot, fsck appeared to be starting on many of the LVs simultaneously.

There was a horrendous sound of disk head movement from the server.

This also makes the whole fsck process slower and therefore the boot
process is slower.

Message #10 received at 776034@bugs.debian.org (full text, mbox, reply):

From: Josh Triplett <josh@joshtriplett.org>

To: 776034@bugs.debian.org

Subject: Re: fsck runs in parallel on same physical disk

Date: Fri, 23 Jan 2015 14:18:10 -0800

On Fri, 23 Jan 2015 07:44:57 +0100 Daniel Pocock <daniel@pocock.pro> wrote:
> I have a server with many LVM logical volumes on top of the same RAID1
> md device on two spindles.
> 
> At boot, fsck appeared to be starting on many of the LVs simultaneously.
> 
> There was a horrendous sound of disk head movement from the server.
> 
> This also makes the whole fsck process slower and therefore the boot
> process is slower.

systemd-fsck is supposed to avoid this.  According to its manpage:

> The file system check for root is performed before the other file
> systems. Other file systems may be checked in parallel, except when
> they are one the same rotating disk.

Does your LVM setup provide the correct value for "rotational"?  What
does the following command say:

sudo find /sys -name 'rotational' -exec head {} +

- Josh Triplett

Message #15 received at 776034@bugs.debian.org (full text, mbox, reply):

From: Michael Biebl <biebl@debian.org>

To: Daniel Pocock <daniel@pocock.pro>, 776034@bugs.debian.org

Subject: Re: Bug#776034: fsck runs in parallel on same physical disk

Date: Mon, 26 Jan 2015 02:06:53 +0100

[Message part 1 (text/plain, inline)]

control: severity -1 important

Am 23.01.2015 um 07:44 schrieb Daniel Pocock:
> Package: systemd
> Version: 215-8
> Severity: serious
> 
> 
> I have a server with many LVM logical volumes on top of the same RAID1
> md device on two spindles.
> 
> At boot, fsck appeared to be starting on many of the LVs simultaneously.
> 
> There was a horrendous sound of disk head movement from the server.
> 
> This also makes the whole fsck process slower and therefore the boot
> process is slower.

As Josh said, systemd-fsck should avoid parallel fsck processes for the
same physical disk. That said, having concurrent disk access is not
something special which would warrant an RC bug.

Therefore downgrading.


-- 
Why is it that all of the instruments seeking intelligent life in the
universe are pointed away from Earth?

[signature.asc (application/pgp-signature, attachment)]

Message #24 received at 776034@bugs.debian.org (full text, mbox, reply):

From: Michael Biebl <biebl@debian.org>

To: Josh Triplett <josh@joshtriplett.org>, 776034@bugs.debian.org

Cc: Daniel Pocock <daniel@pocock.pro>, Karel Zak <kzak@redhat.com>

Subject: Re: Bug#776034: fsck runs in parallel on same physical disk

Date: Mon, 26 Jan 2015 02:17:41 +0100

[Message part 1 (text/plain, inline)]

Am 23.01.2015 um 23:18 schrieb Josh Triplett:
> On Fri, 23 Jan 2015 07:44:57 +0100 Daniel Pocock <daniel@pocock.pro> wrote:
>> I have a server with many LVM logical volumes on top of the same RAID1
>> md device on two spindles.
>>
>> At boot, fsck appeared to be starting on many of the LVs simultaneously.

[..]

> systemd-fsck is supposed to avoid this.  According to its manpage:

Looking further into this, systemd-fsck simply runs
"fsck -l". The "-l" option is supposed to create a lock for the whole
disk device.

Might be, that util-linux's fsck -l does not properly deal with LVM on
top of software RAID.

CCed Karel, maybe he can comment on this.


Daniel, which version of util-linux do you have installed?


-- 
Why is it that all of the instruments seeking intelligent life in the
universe are pointed away from Earth?

[signature.asc (application/pgp-signature, attachment)]

Message #29 received at 776034@bugs.debian.org (full text, mbox, reply):

From: Michael Biebl <biebl@debian.org>

To: Josh Triplett <josh@joshtriplett.org>, 776034@bugs.debian.org

Cc: Daniel Pocock <daniel@pocock.pro>, Karel Zak <kzak@redhat.com>

Subject: Re: Bug#776034: fsck runs in parallel on same physical disk

Date: Mon, 26 Jan 2015 02:24:04 +0100

[Message part 1 (text/plain, inline)]

control: reassign -1 util-linux
control: retitle -1 fsck -l does not work for stacked devices (MD, DM)

Am 26.01.2015 um 02:17 schrieb Michael Biebl:

> Might be, that util-linux's fsck -l does not properly deal with LVM on
> top of software RAID.
> 
> CCed Karel, maybe he can comment on this.

Oh well, should have read the fsck man page more carefully:



>        -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?


> Daniel, which version of util-linux do you have installed?

This information would still be useful, so we can tag the bug accordingly.



-- 
Why is it that all of the instruments seeking intelligent life in the
universe are pointed away from Earth?

[signature.asc (application/pgp-signature, attachment)]

Message #40 received at 776034@bugs.debian.org (full text, mbox, reply):

From: Daniel Pocock <daniel@pocock.pro>

To: Michael Biebl <biebl@debian.org>, Josh Triplett <josh@joshtriplett.org>, 776034@bugs.debian.org

Cc: Karel Zak <kzak@redhat.com>

Subject: Re: Bug#776034: fsck runs in parallel on same physical disk

Date: Mon, 26 Jan 2015 07:10:04 +0100

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256



On 26/01/15 02:24, Michael Biebl wrote:
> control: reassign -1 util-linux control: retitle -1 fsck -l does
> not work for stacked devices (MD, DM)
> 
> Am 26.01.2015 um 02:17 schrieb Michael Biebl:
> 
>> Might be, that util-linux's fsck -l does not properly deal with
>> LVM on top of software RAID.
>> 
>> CCed Karel, maybe he can comment on this.
> 
> Oh well, should have read the fsck man page more carefully:
> 
> 
> 
>> -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?
> 
> 
>> Daniel, which version of util-linux do you have installed?
> 
> This information would still be useful, so we can tag the bug
> accordingly.
> 
> 

It is 2.25.2-4
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.12 (GNU/Linux)
Comment: Using GnuPG with Icedove - http://www.enigmail.net/

iQIcBAEBCAAGBQJUxdo7AAoJEOm1uwJp1aqDihAP+wXLBlsUtm15bdxmqnwgD9m9
pIE7q5Xl1UfW90oo1j8tqhH5WceFMxQu9WmyaiWRP/+crl4iGnEVRJWf/yp1kzeF
6Yu8MA1KrEBp+RTgTUeGph231Lyr/dXx2aHSIk/yHlJ3KvrsfrrEG4pJ60uC1fEa
RvcCpcnNHNy8cppPEzA2Hm7hYCXwCb07j85h57t044Zdor886Jvq+qeycc829Z5p
KKsLLNYBh1DH84hY7tG1xEHe6nDy8gPuVGL2/l0CGqxDs+DW/4ESMinGX6A28bEE
9AbgU5++jRob+2ycbw9l+IcPtrYTrFFL7JwemavHsnZ4HMhaF695GCW2bMbT3LG0
Z+h0ayC66zcp+PDefmyfMQ1OPfKdJ+d7unb7XS9vHui7D2JoVOXizlmrpA2q06uZ
d5XySJywcHdr+WqFeJpLMVtnmGGaSNQrl8VDLWz/adoEpTi3RXbElp9Rvf6jCky6
uV9aAp4QuAVT7Pu/Brnla0fHK/e990L/ZkCOqrYvsPs0ghvJLXdxcc6uVlkLrNkS
yD9ySxTlu/MODOJekXXhB9RyKTmCs3leEHoSOwIfA4mxCAzjjWyEkL/ER2n64ndF
cL/3/wlNHTzZLDGzlH/tImZGl9fsiDQAEQq5mqiJmgcmuMicLKXYZlm1KsbC8Lwo
I//V6Z1N2FYxIyN1oS35
=0loy
-----END PGP SIGNATURE-----

Message #49 received at 776034@bugs.debian.org (full text, mbox, reply):

From: Karel Zak <kzak@redhat.com>

To: Michael Biebl <biebl@debian.org>

Cc: Josh Triplett <josh@joshtriplett.org>, 776034@bugs.debian.org, Daniel Pocock <daniel@pocock.pro>

Subject: Re: Bug#776034: fsck runs in parallel on same physical disk

Date: Mon, 26 Jan 2015 10:32:07 +0100

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

-- 
 Karel Zak  <kzak@redhat.com>
 http://karelzak.blogspot.com

Message #54 received at 776034@bugs.debian.org (full text, mbox, reply):

From: Daniel Pocock <daniel@pocock.pro>

To: Karel Zak <kzak@redhat.com>, Michael Biebl <biebl@debian.org>

Cc: Josh Triplett <josh@joshtriplett.org>, 776034@bugs.debian.org

Subject: Re: Bug#776034: fsck runs in parallel on same physical disk

Date: Mon, 26 Jan 2015 10:36:02 +0100

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?

Message #59 received at 776034@bugs.debian.org (full text, mbox, reply):

From: Karel Zak <kzak@redhat.com>

To: Daniel Pocock <daniel@pocock.pro>

Cc: Michael Biebl <biebl@debian.org>, Josh Triplett <josh@joshtriplett.org>, 776034@bugs.debian.org

Subject: Re: Bug#776034: fsck runs in parallel on same physical disk

Date: Mon, 26 Jan 2015 13:21:08 +0100

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  <kzak@redhat.com>
 http://karelzak.blogspot.com

Message #64 received at 776034@bugs.debian.org (full text, mbox, reply):

From: Daniel Pocock <daniel@pocock.pro>

To: Karel Zak <kzak@redhat.com>

Cc: Michael Biebl <biebl@debian.org>, Josh Triplett <josh@joshtriplett.org>, 776034@bugs.debian.org

Subject: Re: Bug#776034: fsck runs in parallel on same physical disk

Date: Mon, 26 Jan 2015 13:34:19 +0100

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.

Message #69 received at 776034@bugs.debian.org (full text, mbox, reply):

From: Phillip Susi <psusi@ubuntu.com>

To: Daniel Pocock <daniel@pocock.pro>, 776034@bugs.debian.org, Karel Zak <kzak@redhat.com>

Cc: Michael Biebl <biebl@debian.org>, Josh Triplett <josh@joshtriplett.org>

Subject: Re: Bug#776034: fsck runs in parallel on same physical disk

Date: Mon, 26 Jan 2015 08:51:05 -0500

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On 1/26/2015 7:34 AM, Daniel Pocock wrote:
> 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.

Why on earth are you fscking all of those volumes at once?  Use a
journaling filesystem ( ext4?  xfs? ) and you shouldn't really ever
need to fsck at all.


-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.17 (MingW32)

iQEcBAEBAgAGBQJUxkZJAAoJENRVrw2cjl5RPywH/RvUti6Xn8EUi8CBVBe8G1xU
ViahLvk3Q+vMZxNHASg7pbjXMBzosBks28+kd5lqZ/LGm9vNBXTmmEctUwwG/RHZ
yT9kiOg8A/czkW9N4enEZ7Qtb/bq8fH9Cc4uqEDvKxJFZN8hr0I9W9KE/hfYGv28
B3o9qEbyrzv6VsC9UjeA2b+/1taQFUp3KKcM0s/maXJef9JufzTilVkT8lb1cUMd
/4/oWB4HUywG/ArMP8eCogy/0jsJSLWIPs0bAvmUVBo2YnfOFuBn67cuF7Z3a6ZG
OtaKbIExqlyDrT4/Jo+nfsXYpt9h48AKtjESUuqX4C7xB2hMob8q5yOPx65/IKY=
=+qtc
-----END PGP SIGNATURE-----

Message #74 received at 776034@bugs.debian.org (full text, mbox, reply):

From: Daniel Pocock <daniel@pocock.pro>

To: Phillip Susi <psusi@ubuntu.com>, 776034@bugs.debian.org, Karel Zak <kzak@redhat.com>

Cc: Michael Biebl <biebl@debian.org>, Josh Triplett <josh@joshtriplett.org>

Subject: Re: Bug#776034: fsck runs in parallel on same physical disk

Date: Mon, 26 Jan 2015 18:23:28 +0100

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256



On 26/01/15 14:51, Phillip Susi wrote:
> On 1/26/2015 7:34 AM, Daniel Pocock wrote:
>> 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.
> 
> Why on earth are you fscking all of those volumes at once?  Use a 
> journaling filesystem ( ext4?  xfs? ) and you shouldn't really
> ever need to fsck at all.
> 
> 

I just upgraded the machine from wheezy to jessie and systemd decided
to fsck them all when it booted.

The machine had also been running for a long time on wheezy, they
hadn't been checked for 430 days before the upgrade.

About half of them had already been changed to ext4 but there were
quite a few older filesystems there that I haven't updated yet.
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.12 (GNU/Linux)
Comment: Using GnuPG with Icedove - http://www.enigmail.net/

iQIcBAEBCAAGBQJUxngQAAoJEOm1uwJp1aqDn6UQAILRzkXFYe18M26q3CuZjdVt
hGjKK91WLMU5i75YbHDCW04INv9VwVczZLPcIbs6mw372lfdFYLn37aktunv+ayl
wBk7sgYnt5o4Npj4GYSNsIbodiAGQdVwiEG6vVWsieXBAeYn/qtn44IfHOUEr7uN
x3CyuibBrngtOn+QzQfZ8bXqugA5bPlK/F+PscN5k000A5VyWJgZKLTk39mmI47E
rjfUn0LZpTypn14dprKiRitvnwKQa3GMUiiJ4yXpx0NWxkVuwhnPZvE7BiuRMYDO
DuIlC+i8R1iHdEf+TMzEXiJBXfF0+WbRVC7dprFS79pjSvUELIr4Lgjr5+SVc0sS
CLjwRN6ofVlh1TIQNTf+My4+JTmHE1JiTt5smD2mCEc6C/3jH/dKACAWeud7MNmX
pBx+/q35be4yZhjj41spdYgTglEPixnT/1fIVfsmJUCBtMaW3eo9Xwu4XThmtVck
Uq5wAtfPTUHS8JeekDIoSAUp1bNrANZhPUV65AFsA7HyCJpfM7oujQQP92d4w7mD
JlobHcCF0+Yss1zbsQPAqWUm6HNyzdgKkGhZgMZNeMclO/Xq2u8xQi3fMUqzwGF7
YSaDqDvg6pG+8CS5JfRjzTkLdhA2yvM6K2jVBhpLJpUXMkK0wx6PUozRWyMCU0gX
XX7aiH2kFl9Gir+ymb2Q
=0bfD
-----END PGP SIGNATURE-----

Message #81 received at 776034@bugs.debian.org (full text, mbox, reply):

From: Ivan Baldo <ibaldo@adinet.com.uy>

To: 776034@bugs.debian.org

Subject: re: fsck runs in parallel on same physical disk

Date: Fri, 13 Feb 2015 11:05:59 -0200

    Hello.
    This is my opinion FWIW: there should be two bugs not one.
    One wishlist bug for util-linux to implement -l for LVM and MD; if 
the kernel needs an interface to implement this, then report a wishlist 
bug for the Linux kernel to implement the required interface; so maybe 
one day we can have optimal fsck's.
    Another normal (or maybe important) bug for systemd to not launch 
fsck's for LVM or MD devices in parallel, wait for all other running 
fscks to finish, then launch one and only one fsck for LVM or MD, etc.; 
thats what fsck -A does, if systemd cannot do it better then just use 
fsck -A that works correctly, don't reinvent an inferior wheel!
    Thanks for caring! :-)

-- 
Ivan Baldo - ibaldo@adinet.com.uy - http://ibaldo.codigolibre.net/
From Montevideo, Uruguay, at the south of South America.
Freelance programmer and GNU/Linux system administrator, hire me!
Alternatives: ibaldo@codigolibre.net - http://go.to/ibaldo

Message #86 received at 776034@bugs.debian.org (full text, mbox, reply):

From: Andreas Henriksson <andreas@fatal.se>

To: 776034@bugs.debian.org

Subject: fsck raid bug administrative housekeeping

Date: Thu, 12 Nov 2015 22:40:18 +0100

Control: forcemerge -1 779051
Control: severity -1 wishlist
Control: retitle -1 fsck: implement support for stacked devices (MD/DM/RAID)
Control: tags -1 + help upstream

Hello.

Merging duplicate bug report, setting appropriate severity for
feature requests (as already discussed this has never and has no immediate
plans to be implemented), and adjusting title slightly and tagging.
If anyone is interested in sponsoring the implementation of this feature
please speak up.

Regards,
Andreas Henriksson

Send a report that this bug log contains spam.