linux-ext4 - Re: [PATCH e2fsprogs] Add ZFS detection to libblkid

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-id: <1239650962.18123.44.camel@localhost>
Date:	Mon, 13 Apr 2009 20:29:22 +0100
From:	"Ricardo M. Correia" <Ricardo.M.Correia@....COM>
To:	Andreas Dilger <adilger@....COM>
Cc:	Eric Sandeen <sandeen@...hat.com>, "Theodore Ts'o" <tytso@....edu>,
	linux-ext4@...r.kernel.org, Karel Zak <kzak@...hat.com>
Subject: Re: [PATCH e2fsprogs] Add ZFS detection to libblkid

On Ter, 2009-04-07 at 00:40 -0700, Andreas Dilger wrote:
> > However, even though currently it's txg nr 4 that gets written first,
> > this is an implementation-specific detail that we cannot (or should not)
> > rely upon.
> 
> So my proposal to check the 0th, 4th, and 8th überblock in both
> the first and second VDEV label should be pretty safe.

Yes, that should be relatively safe :)

Where should I be sending patches for this? e2fsprogs, util-linux-ng,
libvolume_id in udev, ... all of them?

> > If this is not done, then maybe leaving the ZFS labels intact could be
> > better, so that the user has a chance to recover (some/most) of it's
> > data, in case he made a mistake.
> 
> Well, if ZFS is currently using this filesystem, then the kernel will
> have the block device open O_EXCL, which will prevent the mkfs from
> happening.

Not if the pool is exported :)

> Whether it will be a feature to "--force" mkfs to overwrite an ext3
> superblock or ZFS superblock is questionable.  The problem with needing
> "--force" is that people tend to hard-code this into their scripts
> (so that their script always works) and then due to only having a single
> "--force" flag it also forces other, possibly more destructive, behaviour
> (e.g. --force is needed to mke2fs on a file so that it can be mounted
> via loopback, but will also force mke2fs on a filesystem that actually
> IS in use, etc).

What about '--force-overwrite' or something similar?

It wasn't scripts that I was so concerned about. I think this filesystem
detection would be more useful when running mkfs in a shell, where it is
more likely for the user to make mistakes (e.g. mistype /dev/sdd1
as /dev/sde1 or /dev/sda1 as /dev/sda2).

Thanks,
Ricardo

--
To unsubscribe from this list: send the line "unsubscribe linux-ext4" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html