Your message dated Sun, 3 May 2020 22:18:39 +0200
with message-id <[email protected]>
and subject line Re: Bug#776034: fsck raid bug administrative housekeeping
has caused the Debian Bug report #776034,
regarding fsck: implement support for stacked devices (MD/DM/RAID)
to be marked as done.
This means that you claim that the problem has been dealt with.
If this is not the case it is now your responsibility to reopen the
Bug report if necessary, and/or fix the problem forthwith.
(NB: If you are a system administrator and have no idea what this
message is talking about, this may indicate a serious mail system
misconfiguration somewhere. Please contact [email protected]
immediately.)
--
776034: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=776034
Debian Bug Tracking System
Contact [email protected] with problems
--- Begin Message ---
Package: util-linux
Severity: wishlist
Please add support for detecting RAID array membership and skip
attempting to read partition tables of disks that are members of an
array. Or, if already doing so for linux software RAID, please add
support for fakeraid.
As you can read in the discussion that took place under bug #778712, a
few days ago I was attempting to write a GPT partition table to a
fakeraid RAID0 array that I had just setup using my motherboard firmware
(not knowing at the time that linux software RAID is better supported
and recommended unless dual booting with Windows).
This turned into a confusing mess leaving me thinking that parted might
have a grave bug. Actually it was just a combination of:
1) parted not understanding RAID array membership, resulting in
confusing info being output.
2) fdisk also not understanding RAID array membership, resulting in
confusing info and an error being ouput.
3) fdisk (understandably) not flushing the disk caches of the member
disks after writing a partition table to the array, thus leading me to
think that doing 'parted -l' afterwards was modifying the disk, breaking
things, when in fact all it was doing was flushing the caches, allowing
the true state of things to be revealed in the next use of 'fdisk -l'.
4) My having no clue that any caches were involved in any of this.
5) The (default) stripe size used for the array being 16KiB, small
enough for the GPT table to be split across the two disks, resulting in
it appearing corrupt when the tools viewed an array member as a
standalone disk.
If fdisk flushed every disk cache when performing 'fdisk -l', like
parted does, then I never would have attributed a problem directly to
parted, however I am not advocating such a change, since if only fdisk
and parted understood array membership, then no confusion would have
resulted whatsoever. Please add such support.
--- End Message ---
--- Begin Message ---
* Andreas Henriksson <[email protected]> [200503 20:17]:
> 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.
There is nothing actionable here, as such I don't think Debian's
util-linux needs to track this.
Thanks,
Chris
--- End Message ---
