severity 719195 wishlist thanks On Fri, Aug 09, 2013 at 11:40:51AM +0800, jida...@jidanni.org wrote: > X-Debbugs-Cc: ty...@mit.edu > Package: e2fsprogs > Version: 1.42.8-1 > File: /sbin/e2fsck > > Sometimes fsck can get the word SWAPSPACE2 out of the superblock:
OK, first lesson. There is no standard definition of what is a "superblock" across different file systems or swap devices or LVM systems or MD devices. The FAT file system, for example, uses a 512 byte superblock located at the offset 0 from the beginning of the device or partition. Ext 2/3/4 uses a 1k block size located at offset 1024 from the beginning of the block device. Reiserfs has its superblock located at either offset 8192 or 65536 from the beginning of the file system. LVM puts its signature at the very end of the file system. So your request, "get the word SWAPSPACE2 out of the superblock" has no meaning, because there is no such thing as "the superblock". The bigger problem is at that offset where you were seeing SWAPSPACE2, might be a data block as far as ext2 is concerned. So e2fsck can't just arbitrarily zap the location where SWAPSPACE2 happens to befound. It also doesn't make any sense for e2fsck to know the location of the magic number identifiers of all possible file system or swap space or LVM system. We could code up a special case for SWAPSPACE2, and only zap it if we know that the particular block happens to be unused as far as ext2/3/4 is concerned. But that doesn't solve the general case problem. Fundamentally, the scheme of using in-band signalling is a bad idea, since it is possible for a valid ext2/3/4 file system with a file that happens to be the right (wrong) place to cause a program like gparted to be mistaken. It's for the same reason why telephone systems that could get spoofed by sending 2600HZ tones on the voice channel were inherently insecure, and again, was a funamentally a bad idea. The main problem is 30-year-old MSDOS partition table only has a 8 bit partition type code, and it's historically not reliably set to a correct value. As a result, gparted doesn't trust it, and it tries to use in-band signalling to work around the fact that it doesn't trust the partition table --- not realizing that this is unreliable too. > So we might think debugfs(8) might be useful in this case to 'clear it'. > But alas, it is not. > > Nor can dumpe2fs detect it. > > Only strings(1) can. > > And gparted, which coughs on it > https://bugzilla.gnome.org/show_bug.cgi?id=705597 > and that's why I think it is the job of > fsck to get it out in all cases, not just some. E2fsck is specified to make sure that the file system is consistent as far as ext2/3/4 is concerned. It does that job. So this is not a bug per se in e2fsck. It might be nice if it could fix this, but it's an inherently hard problem, and to be fair, it's not a situation that I would expect would happen all that often. If someone wants to submit a patch, and it's not too horible, I might consider it. But this is a feature request, not a bug. - Ted -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
