On 2011-06-02, at 8:59 AM, Eric Sandeen wrote: > On 6/2/11 2:16 AM, Amir G. wrote: >> OK, after upgrading to newer util-linux and building it from git, >> which also didn't help, I finally found who to blame - me. >> I had an old (noauto) entry in /etc/fstab which claimed that /dev/sda5 is ext4. >> fsck was picking up that entry and insisting that /dev/sda5 is ext4 >> (regardless of what it really is) >> blkid isn't doing that silly thing. > > So where are we at with all this? > > I don't really mind adding ext4dev to FSTYP case statements, it -is- something which blkid could, in theory, still return, and making xfstests cope with that and try to invoke fsck -t ext4dev doesn't bother me too much. It is sadly an fs type embedded into a few tools. I'm perfectly OK with using ext4dev as a filesystem type that allows testing changes to ext4 on a system that is already running ext4 as the root fs. > But other than that, I don't think we should be making changes to upstream projects based on your current development hacks (I don't mean hack in a bad way, just that running sed across ext4 to create your custom filesystem for testing should not require upstream projects to change...) No, but it's not like this is affecting a lot of tools, just one that is used by filesystem developers. > So I'm ok with sprinkling "ext4|ext4dev" around if necessary. Anyone else disagree? The other alternative is to change all of the "ext2|ext3|ext4|ext4dev" case statements to be "ext[2-9]*", or "ext[3-9]*", or "ext[4-9]*" for checks that are only valid for newer codes and be done with it. It's a lot easier to read, and we don't have to change it again should we ever get ext5 or whatever (hopefully btrfs will be ready before that, but who knows). Cheers, Andreas _______________________________________________ xfs mailing list xfs@xxxxxxxxxxx http://oss.sgi.com/mailman/listinfo/xfs
