All of lore.kernel.org
 help / color / mirror / Atom feed
* [PATCH] xfs_mkfs: wipe old signatures from the device
@ 2013-02-12 11:06 Lukas Czerner
  2013-02-12 11:31 ` Karel Zak
  2013-02-12 20:27 ` Dave Chinner
  0 siblings, 2 replies; 27+ messages in thread
From: Lukas Czerner @ 2013-02-12 11:06 UTC (permalink / raw)
  To: xfs; +Cc: sandeen, kzak, Lukas Czerner

We should wipe off all the signatures from the device prior the file
system creation. It is because because some file systems (btrfs) may
still have their signatures on the device which can be confusing for
userspace possibly resulting in the unmountable file system.

This patch adds a function which uses libblkid library to wipe all the
signatures from the device.

If user disables libblkid library or does not have it installed this new
feature will not be used. This case can be implemented separately.

Signed-off-by: Lukas Czerner <lczerner@redhat.com>
---
 mkfs/xfs_mkfs.c |  134 +++++++++++++++++++++++++++++++++++++++---------------
 1 files changed, 97 insertions(+), 37 deletions(-)

diff --git a/mkfs/xfs_mkfs.c b/mkfs/xfs_mkfs.c
index d636549..a889620 100644
--- a/mkfs/xfs_mkfs.c
+++ b/mkfs/xfs_mkfs.c
@@ -286,18 +286,73 @@ calc_stripe_factors(
 }
 
 #ifdef ENABLE_BLKID
+static int
+wipe_signatures(
+	char		*device,
+	int		dryrun)
+{
+	blkid_probe	pr = NULL;
+	int		ret = 0;
+	int		fd;
+
+	pr = blkid_new_probe_from_filename(device);
+	if (!pr)
+		goto out;
+
+	fd = open(device, O_RDWR|O_CLOEXEC);
+	if (fd < 0) {
+		ret = -1;
+		goto out;
+	}
+	ret = blkid_probe_set_device(pr, fd, 0, 0);
+	if (ret)
+		goto out;
+
+	/* No need to check return values we know that 'pr' is initialized */
+	blkid_probe_enable_partitions(pr, 1);
+	blkid_probe_enable_superblocks(pr, 1);
+	blkid_probe_set_partitions_flags(pr, BLKID_PARTS_MAGIC);
+	blkid_probe_set_superblocks_flags(pr,
+					BLKID_SUBLKS_MAGIC | BLKID_SUBLKS_TYPE);
+
+	while (1) {
+		ret = blkid_do_probe(pr);
+		if (ret != 0)
+			break;
+
+		/* Wipe off the signature */
+		ret = blkid_do_wipe(pr, dryrun);
+		if (ret)
+			break;
+	}
+	close(fd);
+
+out:
+	if (pr)
+		blkid_free_probe(pr);
+	if (ret < 0)
+		fprintf(stderr,
+			_("%s: Cannot wipe off existing signatures\n"), progname);
+	return (ret < 0 ? ret : 0);
+}
+
 /*
  * Check for existing filesystem or partition table on device.
  * Returns:
  *	 1 for existing fs or partition
  *	 0 for nothing found
  *	-1 for internal error
+ * If wipe is set, we'll attempt to wipe of all the signatures from
+ * the device. In this case we never return 1 (existing fs or partition).
  */
 static int
 check_overwrite(
-	char		*device)
+	char		*device,
+	int		wipe,
+	int		dryrun)
 {
 	const char	*type;
+	const char	*name;
 	blkid_probe	pr = NULL;
 	int		ret;
 	int		fd;
@@ -325,40 +380,43 @@ check_overwrite(
 	if (!pr)
 		goto out;
 
-	ret = blkid_probe_enable_partitions(pr, 1);
-	if (ret < 0)
-		goto out;
+	/* No need to check return values we know that 'pr' is initialized */
+	blkid_probe_enable_partitions(pr, 1);
+	blkid_probe_enable_superblocks(pr, 1);
+	blkid_probe_set_partitions_flags(pr, BLKID_PARTS_MAGIC);
+	blkid_probe_set_superblocks_flags(pr,
+					BLKID_SUBLKS_MAGIC | BLKID_SUBLKS_TYPE);
 
-	ret = blkid_do_fullprobe(pr);
-	if (ret < 0)
-		goto out;
+	ret = 0;
+	while (1) {
+		int retval = 0;
 
-	/*
-	 * Blkid returns 1 for nothing found and 0 when it finds a signature,
-	 * but we want the exact opposite, so reverse the return value here.
-	 *
-	 * In addition print some useful diagnostics about what actually is
-	 * on the device.
-	 */
-	if (ret) {
-		ret = 0;
-		goto out;
-	}
+		retval = blkid_do_probe(pr);
+		if (retval != 0) {
+			ret = retval;
+			break;
+		}
 
-	if (!blkid_probe_lookup_value(pr, "TYPE", &type, NULL)) {
-		fprintf(stderr,
-			_("%s: %s appears to contain an existing "
-			"filesystem (%s).\n"), progname, device, type);
-	} else if (!blkid_probe_lookup_value(pr, "PTTYPE", &type, NULL)) {
-		fprintf(stderr,
-			_("%s: %s appears to contain a partition "
-			"table (%s).\n"), progname, device, type);
-	} else {
-		fprintf(stderr,
-			_("%s: %s appears to contain something weird "
-			"according to blkid\n"), progname, device);
+		if (blkid_probe_lookup_value(pr, "TYPE", &type, NULL) == 0)
+			name = "filesystem";
+
+		else if (blkid_probe_lookup_value(pr, "PTTYPE",
+						    &type, NULL) == 0)
+			name = "partition table";
+		else
+			continue;
+
+		if (wipe)
+			fprintf(stderr, _("%s: Wiping off %s signature.\n"),
+				progname, type);
+		else {
+			fprintf(stderr,
+				_("%s: %s appears to contain an existing "
+				"%s (%s).\n"), progname, device, name, type);
+			ret = 1;
+			continue;
+		}
 	}
-	ret = 1;
 
 out:
 	if (pr)
@@ -367,6 +425,8 @@ out:
 		fprintf(stderr,
 			_("%s: probe of %s failed, cannot detect "
 			  "existing filesystem.\n"), progname, device);
+	if (ret == 1 && wipe)
+		ret = wipe_signatures(device, dryrun);
 	return ret;
 }
 
@@ -464,7 +524,8 @@ static void get_topology(
 #else /* ENABLE_BLKID */
 static int
 check_overwrite(
-	char		*device)
+	char		*device,
+	int		wipe)
 {
 	char		*type;
 
@@ -1939,16 +2000,15 @@ _("block size %d cannot be smaller than logical sector size %d\n"),
 	xi.rtsize &= sector_mask;
 	xi.logBBsize &= (__uint64_t)-1 << (MAX(lsectorlog, 10) - BBSHIFT);
 
-	if (!force_overwrite) {
-		if (check_overwrite(dfile) ||
-		    check_overwrite(logfile) ||
-		    check_overwrite(xi.rtname)) {
+	if (check_overwrite(dfile, force_overwrite, Nflag) ||
+	    check_overwrite(logfile, force_overwrite, Nflag) ||
+	    check_overwrite(xi.rtname, force_overwrite, Nflag))
+		if (force_overwrite) {
 			fprintf(stderr,
 			_("%s: Use the -f option to force overwrite.\n"),
 				progname);
 			exit(1);
 		}
-	}
 
 	if (discard) {
 		discard_blocks(xi.ddev, xi.dsize);
-- 
1.7.7.6

_______________________________________________
xfs mailing list
xfs@oss.sgi.com
http://oss.sgi.com/mailman/listinfo/xfs

^ permalink raw reply related	[flat|nested] 27+ messages in thread

* Re: [PATCH] xfs_mkfs: wipe old signatures from the device
  2013-02-12 11:06 [PATCH] xfs_mkfs: wipe old signatures from the device Lukas Czerner
@ 2013-02-12 11:31 ` Karel Zak
  2013-02-12 11:58   ` Lukáš Czerner
  2013-02-12 20:27 ` Dave Chinner
  1 sibling, 1 reply; 27+ messages in thread
From: Karel Zak @ 2013-02-12 11:31 UTC (permalink / raw)
  To: Lukas Czerner; +Cc: sandeen, xfs

On Tue, Feb 12, 2013 at 12:06:55PM +0100, Lukas Czerner wrote:
> +wipe_signatures(
> +	char		*device,
> +	int		dryrun)
> +{
> +	blkid_probe	pr = NULL;
> +	int		ret = 0;
> +	int		fd;
> +
> +	pr = blkid_new_probe_from_filename(device);
> +	if (!pr)
> +		goto out;
> +
> +	fd = open(device, O_RDWR|O_CLOEXEC);
> +	if (fd < 0) {
> +		ret = -1;
> +		goto out;
> +	}
> +	ret = blkid_probe_set_device(pr, fd, 0, 0);

 This does not make sense. The blkid_new_probe_from_filename() also
 opens (read-only) the device ;-)

 You need:

   pr = blkid_new_probe();
   if (!pr)
      goto out;

   fd = open(device, O_RDWR|O_CLOEXEC);
   if (fd < 0) {
		ret = -1;
		goto out;
   }
   ret = blkid_probe_set_device(pr, fd, 0, 0);


 Maybe you also need something like
 
   AC_CHECK_LIB(blkid, blkid_do_wipe, [have_blkidwipe=yes], [have_blkidwipe=no])

 or so, because old libblkid versions does not contain wipe stuff. See also
 m4/package_blkid.m4 in xfsprogs where is already check for blkid topology
 stuff.


 Karel

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

_______________________________________________
xfs mailing list
xfs@oss.sgi.com
http://oss.sgi.com/mailman/listinfo/xfs

^ permalink raw reply	[flat|nested] 27+ messages in thread

* Re: [PATCH] xfs_mkfs: wipe old signatures from the device
  2013-02-12 11:31 ` Karel Zak
@ 2013-02-12 11:58   ` Lukáš Czerner
  0 siblings, 0 replies; 27+ messages in thread
From: Lukáš Czerner @ 2013-02-12 11:58 UTC (permalink / raw)
  To: Karel Zak; +Cc: Lukas Czerner, sandeen, xfs

On Tue, 12 Feb 2013, Karel Zak wrote:

> Date: Tue, 12 Feb 2013 12:31:52 +0100
> From: Karel Zak <kzak@redhat.com>
> To: Lukas Czerner <lczerner@redhat.com>
> Cc: xfs@oss.sgi.com, sandeen@redhat.com
> Subject: Re: [PATCH] xfs_mkfs: wipe old signatures from the device
> 
> On Tue, Feb 12, 2013 at 12:06:55PM +0100, Lukas Czerner wrote:
> > +wipe_signatures(
> > +	char		*device,
> > +	int		dryrun)
> > +{
> > +	blkid_probe	pr = NULL;
> > +	int		ret = 0;
> > +	int		fd;
> > +
> > +	pr = blkid_new_probe_from_filename(device);
> > +	if (!pr)
> > +		goto out;
> > +
> > +	fd = open(device, O_RDWR|O_CLOEXEC);
> > +	if (fd < 0) {
> > +		ret = -1;
> > +		goto out;
> > +	}
> > +	ret = blkid_probe_set_device(pr, fd, 0, 0);
> 
>  This does not make sense. The blkid_new_probe_from_filename() also
>  opens (read-only) the device ;-)

Good to know thanks!

-Lukas

> 
>  You need:
> 
>    pr = blkid_new_probe();
>    if (!pr)
>       goto out;
> 
>    fd = open(device, O_RDWR|O_CLOEXEC);
>    if (fd < 0) {
> 		ret = -1;
> 		goto out;
>    }
>    ret = blkid_probe_set_device(pr, fd, 0, 0);
> 
> 
>  Maybe you also need something like
>  
>    AC_CHECK_LIB(blkid, blkid_do_wipe, [have_blkidwipe=yes], [have_blkidwipe=no])
> 
>  or so, because old libblkid versions does not contain wipe stuff. See also
>  m4/package_blkid.m4 in xfsprogs where is already check for blkid topology
>  stuff.
> 
> 
>  Karel
> 
> 

_______________________________________________
xfs mailing list
xfs@oss.sgi.com
http://oss.sgi.com/mailman/listinfo/xfs

^ permalink raw reply	[flat|nested] 27+ messages in thread

* Re: [PATCH] xfs_mkfs: wipe old signatures from the device
  2013-02-12 11:06 [PATCH] xfs_mkfs: wipe old signatures from the device Lukas Czerner
  2013-02-12 11:31 ` Karel Zak
@ 2013-02-12 20:27 ` Dave Chinner
  2013-02-13  8:01   ` Karel Zak
  1 sibling, 1 reply; 27+ messages in thread
From: Dave Chinner @ 2013-02-12 20:27 UTC (permalink / raw)
  To: Lukas Czerner; +Cc: sandeen, kzak, xfs

On Tue, Feb 12, 2013 at 12:06:55PM +0100, Lukas Czerner wrote:
> We should wipe off all the signatures from the device prior the file
> system creation. It is because because some file systems (btrfs) may
> still have their signatures on the device which can be confusing for
> userspace possibly resulting in the unmountable file system.
> 
> This patch adds a function which uses libblkid library to wipe all the
> signatures from the device.
> 
> If user disables libblkid library or does not have it installed this new
> feature will not be used. This case can be implemented separately.

mkfs.xfs already zeros the first part of the block device regardless
of whether it is using libblkid or not:

....
/* amount (in bytes) we zero at the beginning and end of the device to
 * remove traces of other filesystems, raid superblocks, etc.
 */
#define WHACK_SIZE (128 * 1024)
....

        /*
         * Zero out the beginning of the device, to obliterate any old
         * filesystem signatures out there.  This should take care of
         * swap (somewhere around the page size), jfs (32k),
         * ext[2,3] and reiserfs (64k) - and hopefully all else.
         */
        mp->m_ddev_targ.dev = xi.ddev;
        mp->m_ddev_targ.bt_mount = mp;
        buf = libxfs_getbuf(mp->m_ddev_targ, 0, BTOBB(WHACK_SIZE));
        memset(XFS_BUF_PTR(buf), 0, WHACK_SIZE);
        libxfs_writebuf(buf, LIBXFS_EXIT_ON_FAILURE);
        libxfs_purgebuf(buf);

Isn't 128k of zeroing enough to kill existing filesystem signatures?
If not how much is, and why can't we just change WHACK_SIZE to
reflect the size that will kill those signatures that are further
offset into the device?

Cheers,

Dave.
-- 
Dave Chinner
david@fromorbit.com

_______________________________________________
xfs mailing list
xfs@oss.sgi.com
http://oss.sgi.com/mailman/listinfo/xfs

^ permalink raw reply	[flat|nested] 27+ messages in thread

* Re: [PATCH] xfs_mkfs: wipe old signatures from the device
  2013-02-12 20:27 ` Dave Chinner
@ 2013-02-13  8:01   ` Karel Zak
  2013-02-13 10:41     ` Lukáš Czerner
  0 siblings, 1 reply; 27+ messages in thread
From: Karel Zak @ 2013-02-13  8:01 UTC (permalink / raw)
  To: Dave Chinner; +Cc: Lukas Czerner, sandeen, xfs

On Wed, Feb 13, 2013 at 07:27:53AM +1100, Dave Chinner wrote:
> Isn't 128k of zeroing enough to kill existing filesystem signatures?

Really no.

> If not how much is, and why can't we just change WHACK_SIZE to
> reflect the size that will kill those signatures that are further
> offset into the device?

btrfs: first superblock at 64KB, second at 64MB, third at 256GB.

zfs has at least 4 blocks at the begin and end of the device.

GPT has the backup table at the end of the device.

RAIDs have signatures also at the end of the device, etc.


    Karel

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

_______________________________________________
xfs mailing list
xfs@oss.sgi.com
http://oss.sgi.com/mailman/listinfo/xfs

^ permalink raw reply	[flat|nested] 27+ messages in thread

* Re: [PATCH] xfs_mkfs: wipe old signatures from the device
  2013-02-13  8:01   ` Karel Zak
@ 2013-02-13 10:41     ` Lukáš Czerner
  2013-02-13 12:16         ` Karel Zak
  0 siblings, 1 reply; 27+ messages in thread
From: Lukáš Czerner @ 2013-02-13 10:41 UTC (permalink / raw)
  To: Karel Zak; +Cc: sandeen, xfs, Zach Brown, Lukas Czerner, linux-btrfs

On Wed, 13 Feb 2013, Karel Zak wrote:

> Date: Wed, 13 Feb 2013 09:01:54 +0100
> From: Karel Zak <kzak@redhat.com>
> To: Dave Chinner <david@fromorbit.com>
> Cc: Lukas Czerner <lczerner@redhat.com>, xfs@oss.sgi.com, sandeen@redhat.com
> Subject: Re: [PATCH] xfs_mkfs: wipe old signatures from the device
> 
> On Wed, Feb 13, 2013 at 07:27:53AM +1100, Dave Chinner wrote:
> > Isn't 128k of zeroing enough to kill existing filesystem signatures?
> 
> Really no.
> 
> > If not how much is, and why can't we just change WHACK_SIZE to
> > reflect the size that will kill those signatures that are further
> > offset into the device?
> 
> btrfs: first superblock at 64KB, second at 64MB, third at 256GB.

We've been discussing this with Dave and others and it seems really
odd that blkid would detect file system signature from backup
superblock. It seems that it's doing this only for btrfs, ignoring
backup superblocks for any other file system.

I know that btrfs user space is broken in a way that it would
unconditionally use backup superblock, but it has to be fixed!

Also I think that the bug in btrfs is not a reason for blkid to
treat btrfs backup superblocks as primary (which is what you're
essentially doing). We should fix that first and then we can discuss
whether fs utilities should be using blkid to wipe all the
signatures from the device I think.

It seem to me that this is real problem and also nasty regression
because:

mkfs.btrfs /dev/sda
mkfs.xfs -f /dev/sda

and the device is unmountable, even though it contains valid xfs
file system.

However

mkfs.btrfs /dev/sda
mkfs.ext4 -F /dev/sda

works well, however I am not sure why that is. Is that some kind of
mount(8) magic ?

So I think that liblkid _and_ btrfs tools has to be fixed not to treat
backup superblocks as primary!

Thanks!
-Lukas


> 
> zfs has at least 4 blocks at the begin and end of the device.
> 
> GPT has the backup table at the end of the device.
> 
> RAIDs have signatures also at the end of the device, etc.
> 
> 
>     Karel
> 
> 

_______________________________________________
xfs mailing list
xfs@oss.sgi.com
http://oss.sgi.com/mailman/listinfo/xfs

^ permalink raw reply	[flat|nested] 27+ messages in thread

* Re: [PATCH] xfs_mkfs: wipe old signatures from the device
  2013-02-13 10:41     ` Lukáš Czerner
@ 2013-02-13 12:16         ` Karel Zak
  0 siblings, 0 replies; 27+ messages in thread
From: Karel Zak @ 2013-02-13 12:16 UTC (permalink / raw)
  To: Lukáš Czerner
  Cc: Dave Chinner, xfs, sandeen, Zach Brown, linux-btrfs

On Wed, Feb 13, 2013 at 11:41:08AM +0100, Lukáš Czerner wrote:
> However
> 
> mkfs.btrfs /dev/sda
> mkfs.ext4 -F /dev/sda
> 
> works well, however I am not sure why that is. Is that some kind of
> mount(8) magic ?

 This is bug in libmount. Fixed in upstream tree. The libmount in some
 cases ignores the ambivalent probing result from libblkid and tries 
 stuff from /etc/filesystems (where is for example ext4).

> So I think that liblkid _and_ btrfs tools has to be fixed not to treat
> backup superblocks as primary!

 The problem with additional btrfs superblocks has been already reported
 to btrfs guys:

   http://www.mail-archive.com/linux-btrfs@vger.kernel.org/msg20957.html

 and I don't see a reply "yep, this is btrfs-progs bug" :-)

    Karel

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

^ permalink raw reply	[flat|nested] 27+ messages in thread

* Re: [PATCH] xfs_mkfs: wipe old signatures from the device
@ 2013-02-13 12:16         ` Karel Zak
  0 siblings, 0 replies; 27+ messages in thread
From: Karel Zak @ 2013-02-13 12:16 UTC (permalink / raw)
  To: Lukáš Czerner; +Cc: Zach Brown, sandeen, linux-btrfs, xfs

On Wed, Feb 13, 2013 at 11:41:08AM +0100, Lukáš Czerner wrote:
> However
> 
> mkfs.btrfs /dev/sda
> mkfs.ext4 -F /dev/sda
> 
> works well, however I am not sure why that is. Is that some kind of
> mount(8) magic ?

 This is bug in libmount. Fixed in upstream tree. The libmount in some
 cases ignores the ambivalent probing result from libblkid and tries 
 stuff from /etc/filesystems (where is for example ext4).

> So I think that liblkid _and_ btrfs tools has to be fixed not to treat
> backup superblocks as primary!

 The problem with additional btrfs superblocks has been already reported
 to btrfs guys:

   http://www.mail-archive.com/linux-btrfs@vger.kernel.org/msg20957.html

 and I don't see a reply "yep, this is btrfs-progs bug" :-)

    Karel

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

_______________________________________________
xfs mailing list
xfs@oss.sgi.com
http://oss.sgi.com/mailman/listinfo/xfs

^ permalink raw reply	[flat|nested] 27+ messages in thread

* Re: [PATCH] xfs_mkfs: wipe old signatures from the device
  2013-02-13 12:16         ` Karel Zak
@ 2013-02-13 22:17           ` Dave Chinner
  -1 siblings, 0 replies; 27+ messages in thread
From: Dave Chinner @ 2013-02-13 22:17 UTC (permalink / raw)
  To: Karel Zak; +Cc: Lukáš Czerner, xfs, sandeen, Zach Brown, linux-btrfs

On Wed, Feb 13, 2013 at 01:16:55PM +0100, Karel Zak wrote:
> On Wed, Feb 13, 2013 at 11:41:08AM +0100, Lukáš Czerner wrote:
> > However
> > 
> > mkfs.btrfs /dev/sda
> > mkfs.ext4 -F /dev/sda
> > 
> > works well, however I am not sure why that is. Is that some kind of
> > mount(8) magic ?
> 
>  This is bug in libmount. Fixed in upstream tree. The libmount in some
>  cases ignores the ambivalent probing result from libblkid and tries 
>  stuff from /etc/filesystems (where is for example ext4).
> 
> > So I think that liblkid _and_ btrfs tools has to be fixed not to treat
> > backup superblocks as primary!
> 
>  The problem with additional btrfs superblocks has been already reported
>  to btrfs guys:
> 
>    http://www.mail-archive.com/linux-btrfs@vger.kernel.org/msg20957.html
> 
>  and I don't see a reply "yep, this is btrfs-progs bug" :-)

Oh, it's most definitely a btrfs-progs bug. Using stale
metadata data on the block device in preference to current, primary
metadata identifying the device to belong to a different filesystem
is, well, rather unfriendly.

In the above case, mkfs.ext4 overwrites the btrfs magic block field
so that it is not zero (as it is after wipefs runs), and hence the
btrfs tools see it as a broken superblock and continue to the next
location for recovery rather than see the device as containing a
valid but foreign filesystem.

None of the filesystem tools from ext4, btrfs and XFS handle this
sort of thing consistently, even though it is their responsibility
to do so. XFS is probably the best of them, in that *some* of the
tools will refuse to run unless you provide a force flag when the
device appears to contain primary identifiers for a different
filesystem. e.g. mkfs.xfs won't overwrite existing filesystems
without a force flag, but mkfs.ext4 and mkfs.btrfs will:

$ sudo mkfs.xfs /dev/vdb
mkfs.xfs: /dev/vdb appears to contain an existing filesystem (btrfs).
mkfs.xfs: Use the -f option to force overwrite.
$ sudo mkfs.xfs -f /dev/vdb
meta-data=/dev/vdb               isize=256    agcount=4, agsize=720896 blks
         =                       sectsz=512   attr=2, projid32bit=0
         =                       crc=0    
data     =                       bsize=4096   blocks=2883584, imaxpct=25
         =                       sunit=0      swidth=0 blks
naming   =version 2              bsize=4096   ascii-ci=0
log      =internal log           bsize=4096   blocks=2560, version=2
         =                       sectsz=512   sunit=0 blks, lazy-count=1
realtime =none                   extsz=4096   blocks=0, rtextents=0
$ sudo mkfs.xfs /dev/vdb
mkfs.xfs: /dev/vdb appears to contain an existing filesystem (xfs).
mkfs.xfs: Use the -f option to force overwrite.
$ sudo mkfs.btrfs /dev/vdb

WARNING! - Btrfs Btrfs v0.19 IS EXPERIMENTAL
WARNING! - see http://btrfs.wiki.kernel.org before using

fs created label (null) on /dev/vdb
        nodesize 4096 leafsize 4096 sectorsize 4096 size 11.00GB
Btrfs Btrfs v0.19
$ sudo mkfs.ext4 /dev/vdb
mke2fs 1.42.5 (29-Jul-2012)
Filesystem label=
OS type: Linux
Block size=4096 (log=2)
Fragment size=4096 (log=2)
Stride=0 blocks, Stripe width=0 blocks
720896 inodes, 2883584 blocks
144179 blocks (5.00%) reserved for the super user
First data block=0
Maximum filesystem blocks=2952790016
88 block groups
32768 blocks per group, 32768 fragments per group
8192 inodes per group
Superblock backups stored on blocks: 
        32768, 98304, 163840, 229376, 294912, 819200, 884736, 1605632, 2654208

Allocating group tables: done                            
Writing inode tables: done                            
Creating journal (32768 blocks): done
Writing superblocks and filesystem accounting information: done 

$ sudo mkfs.xfs /dev/vdb
mkfs.xfs: /dev/vdb appears to contain an existing filesystem (ext4).
mkfs.xfs: Use the -f option to force overwrite.
$

IOWs, it is the responsibility of the filesystem tools to correctly
identify the filesystem being operated on, and not to
modify/trash/recover anything unless specifically directed by the
user.  When a filesystem tool gets it wrong, then that specific tool
needs to be fixed.  i.e. it is the responsibility of filesystem
tools to behave sanely, not for the rest of the world to have to
work around the dangerous behaviour of a specific filesystems'
toolset.

And that makes it a btrfs-progs bug that needs to be fixed.

Cheers,

Dave.
-- 
Dave Chinner
david@fromorbit.com

^ permalink raw reply	[flat|nested] 27+ messages in thread

* Re: [PATCH] xfs_mkfs: wipe old signatures from the device
@ 2013-02-13 22:17           ` Dave Chinner
  0 siblings, 0 replies; 27+ messages in thread
From: Dave Chinner @ 2013-02-13 22:17 UTC (permalink / raw)
  To: Karel Zak; +Cc: Zach Brown, Lukáš Czerner, sandeen, linux-btrfs, xfs

On Wed, Feb 13, 2013 at 01:16:55PM +0100, Karel Zak wrote:
> On Wed, Feb 13, 2013 at 11:41:08AM +0100, Lukáš Czerner wrote:
> > However
> > 
> > mkfs.btrfs /dev/sda
> > mkfs.ext4 -F /dev/sda
> > 
> > works well, however I am not sure why that is. Is that some kind of
> > mount(8) magic ?
> 
>  This is bug in libmount. Fixed in upstream tree. The libmount in some
>  cases ignores the ambivalent probing result from libblkid and tries 
>  stuff from /etc/filesystems (where is for example ext4).
> 
> > So I think that liblkid _and_ btrfs tools has to be fixed not to treat
> > backup superblocks as primary!
> 
>  The problem with additional btrfs superblocks has been already reported
>  to btrfs guys:
> 
>    http://www.mail-archive.com/linux-btrfs@vger.kernel.org/msg20957.html
> 
>  and I don't see a reply "yep, this is btrfs-progs bug" :-)

Oh, it's most definitely a btrfs-progs bug. Using stale
metadata data on the block device in preference to current, primary
metadata identifying the device to belong to a different filesystem
is, well, rather unfriendly.

In the above case, mkfs.ext4 overwrites the btrfs magic block field
so that it is not zero (as it is after wipefs runs), and hence the
btrfs tools see it as a broken superblock and continue to the next
location for recovery rather than see the device as containing a
valid but foreign filesystem.

None of the filesystem tools from ext4, btrfs and XFS handle this
sort of thing consistently, even though it is their responsibility
to do so. XFS is probably the best of them, in that *some* of the
tools will refuse to run unless you provide a force flag when the
device appears to contain primary identifiers for a different
filesystem. e.g. mkfs.xfs won't overwrite existing filesystems
without a force flag, but mkfs.ext4 and mkfs.btrfs will:

$ sudo mkfs.xfs /dev/vdb
mkfs.xfs: /dev/vdb appears to contain an existing filesystem (btrfs).
mkfs.xfs: Use the -f option to force overwrite.
$ sudo mkfs.xfs -f /dev/vdb
meta-data=/dev/vdb               isize=256    agcount=4, agsize=720896 blks
         =                       sectsz=512   attr=2, projid32bit=0
         =                       crc=0    
data     =                       bsize=4096   blocks=2883584, imaxpct=25
         =                       sunit=0      swidth=0 blks
naming   =version 2              bsize=4096   ascii-ci=0
log      =internal log           bsize=4096   blocks=2560, version=2
         =                       sectsz=512   sunit=0 blks, lazy-count=1
realtime =none                   extsz=4096   blocks=0, rtextents=0
$ sudo mkfs.xfs /dev/vdb
mkfs.xfs: /dev/vdb appears to contain an existing filesystem (xfs).
mkfs.xfs: Use the -f option to force overwrite.
$ sudo mkfs.btrfs /dev/vdb

WARNING! - Btrfs Btrfs v0.19 IS EXPERIMENTAL
WARNING! - see http://btrfs.wiki.kernel.org before using

fs created label (null) on /dev/vdb
        nodesize 4096 leafsize 4096 sectorsize 4096 size 11.00GB
Btrfs Btrfs v0.19
$ sudo mkfs.ext4 /dev/vdb
mke2fs 1.42.5 (29-Jul-2012)
Filesystem label=
OS type: Linux
Block size=4096 (log=2)
Fragment size=4096 (log=2)
Stride=0 blocks, Stripe width=0 blocks
720896 inodes, 2883584 blocks
144179 blocks (5.00%) reserved for the super user
First data block=0
Maximum filesystem blocks=2952790016
88 block groups
32768 blocks per group, 32768 fragments per group
8192 inodes per group
Superblock backups stored on blocks: 
        32768, 98304, 163840, 229376, 294912, 819200, 884736, 1605632, 2654208

Allocating group tables: done                            
Writing inode tables: done                            
Creating journal (32768 blocks): done
Writing superblocks and filesystem accounting information: done 

$ sudo mkfs.xfs /dev/vdb
mkfs.xfs: /dev/vdb appears to contain an existing filesystem (ext4).
mkfs.xfs: Use the -f option to force overwrite.
$

IOWs, it is the responsibility of the filesystem tools to correctly
identify the filesystem being operated on, and not to
modify/trash/recover anything unless specifically directed by the
user.  When a filesystem tool gets it wrong, then that specific tool
needs to be fixed.  i.e. it is the responsibility of filesystem
tools to behave sanely, not for the rest of the world to have to
work around the dangerous behaviour of a specific filesystems'
toolset.

And that makes it a btrfs-progs bug that needs to be fixed.

Cheers,

Dave.
-- 
Dave Chinner
david@fromorbit.com

_______________________________________________
xfs mailing list
xfs@oss.sgi.com
http://oss.sgi.com/mailman/listinfo/xfs

^ permalink raw reply	[flat|nested] 27+ messages in thread

* Re: [PATCH] xfs_mkfs: wipe old signatures from the device
  2013-02-13 22:17           ` Dave Chinner
@ 2013-02-14  7:29             ` Chris Murphy
  -1 siblings, 0 replies; 27+ messages in thread
From: Chris Murphy @ 2013-02-14  7:29 UTC (permalink / raw)
  To: Dave Chinner
  Cc: Karel Zak, Lukáš Czerner, xfs, sandeen, Zach Brown,
	linux-btrfs


On Feb 13, 2013, at 3:17 PM, Dave Chinner <david@fromorbit.com> wrote:
> it is the responsibility of filesystem
> tools to behave sanely, not for the rest of the world to have to
> work around the dangerous behaviour of a specific filesystems'
> toolset.

I appreciate this, and in particular that mkfs.xfs doesn't nerf a file system without the use of -f; even an existing XFS file system. Considering most data loss is user induced, I'd appreciate it if other file systems's tools weren't so easily made belligerent by (hopefully temporarily) confused apes wearing pants.

Chris Murphy

^ permalink raw reply	[flat|nested] 27+ messages in thread

* Re: [PATCH] xfs_mkfs: wipe old signatures from the device
@ 2013-02-14  7:29             ` Chris Murphy
  0 siblings, 0 replies; 27+ messages in thread
From: Chris Murphy @ 2013-02-14  7:29 UTC (permalink / raw)
  To: Dave Chinner
  Cc: sandeen, xfs, Karel Zak, Zach Brown, Lukáš Czerner,
	linux-btrfs


On Feb 13, 2013, at 3:17 PM, Dave Chinner <david@fromorbit.com> wrote:
> it is the responsibility of filesystem
> tools to behave sanely, not for the rest of the world to have to
> work around the dangerous behaviour of a specific filesystems'
> toolset.

I appreciate this, and in particular that mkfs.xfs doesn't nerf a file system without the use of -f; even an existing XFS file system. Considering most data loss is user induced, I'd appreciate it if other file systems's tools weren't so easily made belligerent by (hopefully temporarily) confused apes wearing pants.

Chris Murphy
_______________________________________________
xfs mailing list
xfs@oss.sgi.com
http://oss.sgi.com/mailman/listinfo/xfs

^ permalink raw reply	[flat|nested] 27+ messages in thread

* Re: [PATCH] xfs_mkfs: wipe old signatures from the device
  2013-02-14  7:29             ` Chris Murphy
  (?)
@ 2013-02-14  8:36             ` Lukáš Czerner
  2013-02-14 11:04                 ` Dave Chinner
  2013-02-14 17:25                 ` Eric Sandeen
  -1 siblings, 2 replies; 27+ messages in thread
From: Lukáš Czerner @ 2013-02-14  8:36 UTC (permalink / raw)
  To: Chris Murphy
  Cc: sandeen, xfs, Karel Zak, Zach Brown, Lukáš Czerner,
	linux-btrfs

[-- Attachment #1: Type: TEXT/PLAIN, Size: 1580 bytes --]

On Thu, 14 Feb 2013, Chris Murphy wrote:

> Date: Thu, 14 Feb 2013 00:29:59 -0700
> From: Chris Murphy <lists@colorremedies.com>
> To: Dave Chinner <david@fromorbit.com>
> Cc: Karel Zak <kzak@redhat.com>, Lukáš Czerner <lczerner@redhat.com>,
>     xfs@oss.sgi.com, sandeen@redhat.com, Zach Brown <zabrown@redhat.com>,
>     linux-btrfs@vger.kernel.org
> Subject: Re: [PATCH] xfs_mkfs: wipe old signatures from the device
> 
> 
> On Feb 13, 2013, at 3:17 PM, Dave Chinner <david@fromorbit.com> wrote:
> > it is the responsibility of filesystem
> > tools to behave sanely, not for the rest of the world to have to
> > work around the dangerous behaviour of a specific filesystems'
> > toolset.
> 
> I appreciate this, and in particular that mkfs.xfs doesn't nerf a file system without the use of -f; even an existing XFS file system. Considering most data loss is user induced, I'd appreciate it if other file systems's tools weren't so easily made belligerent by (hopefully temporarily) confused apes wearing pants.
> 
> Chris Murphy

I would not be so optimistic about it. The reason being that there
are almost _always_ old file system signatures on the device. So I
think that it got to the point where users will usually use mkfs.xfs
-f all the time. And even if they did not and they would use a wrong
device they would probably get the same warning even for the device
they wanted to use in the first place.

So even thoug it might help in some cases I do not think that we
should go and change all file systems to do that as well, it would
not be very useful anyway.

-Lukas

[-- Attachment #2: Type: text/plain, Size: 121 bytes --]

_______________________________________________
xfs mailing list
xfs@oss.sgi.com
http://oss.sgi.com/mailman/listinfo/xfs

^ permalink raw reply	[flat|nested] 27+ messages in thread

* Re: [PATCH] xfs_mkfs: wipe old signatures from the device
  2013-02-14  8:36             ` Lukáš Czerner
@ 2013-02-14 11:04                 ` Dave Chinner
  2013-02-14 17:25                 ` Eric Sandeen
  1 sibling, 0 replies; 27+ messages in thread
From: Dave Chinner @ 2013-02-14 11:04 UTC (permalink / raw)
  To: Lukáš Czerner
  Cc: Chris Murphy, Karel Zak, xfs, sandeen, Zach Brown, linux-btrfs

On Thu, Feb 14, 2013 at 09:36:38AM +0100, Lukáš Czerner wrote:
> On Thu, 14 Feb 2013, Chris Murphy wrote:
> 
> > Date: Thu, 14 Feb 2013 00:29:59 -0700
> > From: Chris Murphy <lists@colorremedies.com>
> > To: Dave Chinner <david@fromorbit.com>
> > Cc: Karel Zak <kzak@redhat.com>, Lukáš Czerner <lczerner@redhat.com>,
> >     xfs@oss.sgi.com, sandeen@redhat.com, Zach Brown <zabrown@redhat.com>,
> >     linux-btrfs@vger.kernel.org
> > Subject: Re: [PATCH] xfs_mkfs: wipe old signatures from the device
> > 
> > 
> > On Feb 13, 2013, at 3:17 PM, Dave Chinner <david@fromorbit.com> wrote:
> > > it is the responsibility of filesystem
> > > tools to behave sanely, not for the rest of the world to have to
> > > work around the dangerous behaviour of a specific filesystems'
> > > toolset.
> > 
> > I appreciate this, and in particular that mkfs.xfs doesn't nerf a file system without the use of -f; even an existing XFS file system. Considering most data loss is user induced, I'd appreciate it if other file systems's tools weren't so easily made belligerent by (hopefully temporarily) confused apes wearing pants.
> > 
> > Chris Murphy
> 
> I would not be so optimistic about it. The reason being that there
> are almost _always_ old file system signatures on the device.

That assumption is way off the mark.  What you do as a filesystem
developer (remake filesystems on the same block device hundreds of
times a day) is not at all typical, so you cannot extrapolate from
your usage habits to what typically happens in production
environments.

Admins don't tend to use "force" options by default (especially for
destructive comands like mkfs) as 1) they are rarely necessary in the
real world and 2) the consequences of errors are severe.  The most
common filesystem creation pattern in production systems (be it
desktop, workstation or server) is that storage, devices and
filesystems are set up once and then used for the entire lifetime
ofthe system without ever having mkfs run on them again. i.e on
pristine, empty hardware. Hence users rarely, if ever, need to use
the force option for mkfs.xfs.

> So I
> think that it got to the point where users will usually use mkfs.xfs
> -f all the time. And even if they did not and they would use a wrong
> device they would probably get the same warning even for the device
> they wanted to use in the first place.

I get a couple of queries a year from people saying they
accidentally ran mkfs.ext4 on the wrong device and want to know if
they can recover their XFS filesystem. The next question is usually
"why didn't mkfs.ext4 warn me there was an existing filesystem on
the device like mkfs.xfs does?".

That is why the "don't overwrite an existing filesystem by default"
behaviour is important. Users like to be protected from mistakes
they weren't aware they made, and far too few of our filesystem
utilities provide that safety net.

A couple of users a year losing data like this is a couple of users
too many. Especially when it would only take a couple of hours of
your time to implement....

> So even thoug it might help in some cases I do not think that we
> should go and change all file systems to do that as well, it would
> not be very useful anyway.

Tell that to the next user that trashes their data because a
filesystem tool simply assumed in correctly that it owned the block
device.

Cheers,

Dave.
-- 
Dave Chinner
david@fromorbit.com

^ permalink raw reply	[flat|nested] 27+ messages in thread

* Re: [PATCH] xfs_mkfs: wipe old signatures from the device
@ 2013-02-14 11:04                 ` Dave Chinner
  0 siblings, 0 replies; 27+ messages in thread
From: Dave Chinner @ 2013-02-14 11:04 UTC (permalink / raw)
  To: Lukáš Czerner
  Cc: sandeen, xfs, Karel Zak, Zach Brown, Chris Murphy, linux-btrfs

On Thu, Feb 14, 2013 at 09:36:38AM +0100, Lukáš Czerner wrote:
> On Thu, 14 Feb 2013, Chris Murphy wrote:
> 
> > Date: Thu, 14 Feb 2013 00:29:59 -0700
> > From: Chris Murphy <lists@colorremedies.com>
> > To: Dave Chinner <david@fromorbit.com>
> > Cc: Karel Zak <kzak@redhat.com>, Lukáš Czerner <lczerner@redhat.com>,
> >     xfs@oss.sgi.com, sandeen@redhat.com, Zach Brown <zabrown@redhat.com>,
> >     linux-btrfs@vger.kernel.org
> > Subject: Re: [PATCH] xfs_mkfs: wipe old signatures from the device
> > 
> > 
> > On Feb 13, 2013, at 3:17 PM, Dave Chinner <david@fromorbit.com> wrote:
> > > it is the responsibility of filesystem
> > > tools to behave sanely, not for the rest of the world to have to
> > > work around the dangerous behaviour of a specific filesystems'
> > > toolset.
> > 
> > I appreciate this, and in particular that mkfs.xfs doesn't nerf a file system without the use of -f; even an existing XFS file system. Considering most data loss is user induced, I'd appreciate it if other file systems's tools weren't so easily made belligerent by (hopefully temporarily) confused apes wearing pants.
> > 
> > Chris Murphy
> 
> I would not be so optimistic about it. The reason being that there
> are almost _always_ old file system signatures on the device.

That assumption is way off the mark.  What you do as a filesystem
developer (remake filesystems on the same block device hundreds of
times a day) is not at all typical, so you cannot extrapolate from
your usage habits to what typically happens in production
environments.

Admins don't tend to use "force" options by default (especially for
destructive comands like mkfs) as 1) they are rarely necessary in the
real world and 2) the consequences of errors are severe.  The most
common filesystem creation pattern in production systems (be it
desktop, workstation or server) is that storage, devices and
filesystems are set up once and then used for the entire lifetime
ofthe system without ever having mkfs run on them again. i.e on
pristine, empty hardware. Hence users rarely, if ever, need to use
the force option for mkfs.xfs.

> So I
> think that it got to the point where users will usually use mkfs.xfs
> -f all the time. And even if they did not and they would use a wrong
> device they would probably get the same warning even for the device
> they wanted to use in the first place.

I get a couple of queries a year from people saying they
accidentally ran mkfs.ext4 on the wrong device and want to know if
they can recover their XFS filesystem. The next question is usually
"why didn't mkfs.ext4 warn me there was an existing filesystem on
the device like mkfs.xfs does?".

That is why the "don't overwrite an existing filesystem by default"
behaviour is important. Users like to be protected from mistakes
they weren't aware they made, and far too few of our filesystem
utilities provide that safety net.

A couple of users a year losing data like this is a couple of users
too many. Especially when it would only take a couple of hours of
your time to implement....

> So even thoug it might help in some cases I do not think that we
> should go and change all file systems to do that as well, it would
> not be very useful anyway.

Tell that to the next user that trashes their data because a
filesystem tool simply assumed in correctly that it owned the block
device.

Cheers,

Dave.
-- 
Dave Chinner
david@fromorbit.com

_______________________________________________
xfs mailing list
xfs@oss.sgi.com
http://oss.sgi.com/mailman/listinfo/xfs

^ permalink raw reply	[flat|nested] 27+ messages in thread

* Re: [PATCH] xfs_mkfs: wipe old signatures from the device
  2013-02-13 22:17           ` Dave Chinner
  (?)
  (?)
@ 2013-02-14 11:45           ` Dave Howorth
  2013-02-14 19:17             ` Eric Sandeen
  -1 siblings, 1 reply; 27+ messages in thread
From: Dave Howorth @ 2013-02-14 11:45 UTC (permalink / raw)
  To: xfs

Dave Chinner wrote:
> IOWs, it is the responsibility of the filesystem tools to correctly
> identify the filesystem being operated on, and not to
> modify/trash/recover anything unless specifically directed by the
> user.  When a filesystem tool gets it wrong, then that specific tool
> needs to be fixed.  i.e. it is the responsibility of filesystem
> tools to behave sanely, not for the rest of the world to have to
> work around the dangerous behaviour of a specific filesystems'
> toolset.

As an average Joe user, I started to agree with this, but then as a
developer I had second thoughts. It can't be right that every filesystem
tool has to have code to recognize every other type of filesystem; that
just doesn't scale. So each tool would need to call some API, which I
suppose would need to access some kernel code that iterated for every
filesystem type the kernel was configured to handle, or knew historically.

And then we have identical code in every tool, and that code is not
serving the tool's primary purpose, so maybe it should be factored out
on the one-tool-one-job philosophy. So perhaps there should be a single
tool that tells what filesystem type is present on a device, which
everybody runs before mkfs. Oh wait, df -T or other utilities already do
that.

So I'm not sure the issue is black and white. As an average Joe, I
expect mkfs to trash whatever I give it, so I'm pretty careful to check
what is there first. And if I expected to be overwriting an existing
filesystem and I did it often enough to know about the mkfs.xfs
behaviour, I suppose I would always invoke it with the -f flag.
Consistency among the various flavours of mkfs would be nice, though.

_______________________________________________
xfs mailing list
xfs@oss.sgi.com
http://oss.sgi.com/mailman/listinfo/xfs

^ permalink raw reply	[flat|nested] 27+ messages in thread

* Re: [PATCH] xfs_mkfs: wipe old signatures from the device
  2013-02-14 11:04                 ` Dave Chinner
  (?)
@ 2013-02-14 12:28                 ` Lukáš Czerner
  -1 siblings, 0 replies; 27+ messages in thread
From: Lukáš Czerner @ 2013-02-14 12:28 UTC (permalink / raw)
  To: Dave Chinner
  Cc: sandeen, xfs, Karel Zak, Zach Brown, Lukáš Czerner,
	Chris Murphy, linux-btrfs

[-- Attachment #1: Type: TEXT/PLAIN, Size: 4738 bytes --]

On Thu, 14 Feb 2013, Dave Chinner wrote:

> Date: Thu, 14 Feb 2013 22:04:23 +1100
> From: Dave Chinner <david@fromorbit.com>
> To: Lukáš Czerner <lczerner@redhat.com>
> Cc: Chris Murphy <lists@colorremedies.com>, Karel Zak <kzak@redhat.com>,
>     xfs@oss.sgi.com, sandeen@redhat.com, Zach Brown <zabrown@redhat.com>,
>     linux-btrfs@vger.kernel.org
> Subject: Re: [PATCH] xfs_mkfs: wipe old signatures from the device
> 
> On Thu, Feb 14, 2013 at 09:36:38AM +0100, Lukáš Czerner wrote:
> > On Thu, 14 Feb 2013, Chris Murphy wrote:
> > 
> > > Date: Thu, 14 Feb 2013 00:29:59 -0700
> > > From: Chris Murphy <lists@colorremedies.com>
> > > To: Dave Chinner <david@fromorbit.com>
> > > Cc: Karel Zak <kzak@redhat.com>, Lukáš Czerner <lczerner@redhat.com>,
> > >     xfs@oss.sgi.com, sandeen@redhat.com, Zach Brown <zabrown@redhat.com>,
> > >     linux-btrfs@vger.kernel.org
> > > Subject: Re: [PATCH] xfs_mkfs: wipe old signatures from the device
> > > 
> > > 
> > > On Feb 13, 2013, at 3:17 PM, Dave Chinner <david@fromorbit.com> wrote:
> > > > it is the responsibility of filesystem
> > > > tools to behave sanely, not for the rest of the world to have to
> > > > work around the dangerous behaviour of a specific filesystems'
> > > > toolset.
> > > 
> > > I appreciate this, and in particular that mkfs.xfs doesn't nerf a file system without the use of -f; even an existing XFS file system. Considering most data loss is user induced, I'd appreciate it if other file systems's tools weren't so easily made belligerent by (hopefully temporarily) confused apes wearing pants.
> > > 
> > > Chris Murphy
> > 
> > I would not be so optimistic about it. The reason being that there
> > are almost _always_ old file system signatures on the device.
> 
> That assumption is way off the mark.  What you do as a filesystem
> developer (remake filesystems on the same block device hundreds of
> times a day) is not at all typical, so you cannot extrapolate from
> your usage habits to what typically happens in production
> environments.
> 
> Admins don't tend to use "force" options by default (especially for
> destructive comands like mkfs) as 1) they are rarely necessary in the
> real world and 2) the consequences of errors are severe.  The most
> common filesystem creation pattern in production systems (be it
> desktop, workstation or server) is that storage, devices and
> filesystems are set up once and then used for the entire lifetime
> ofthe system without ever having mkfs run on them again. i.e on
> pristine, empty hardware. Hence users rarely, if ever, need to use
> the force option for mkfs.xfs.
> 
> > So I
> > think that it got to the point where users will usually use mkfs.xfs
> > -f all the time. And even if they did not and they would use a wrong
> > device they would probably get the same warning even for the device
> > they wanted to use in the first place.
> 
> I get a couple of queries a year from people saying they
> accidentally ran mkfs.ext4 on the wrong device and want to know if
> they can recover their XFS filesystem. The next question is usually
> "why didn't mkfs.ext4 warn me there was an existing filesystem on
> the device like mkfs.xfs does?".
> 
> That is why the "don't overwrite an existing filesystem by default"
> behaviour is important. Users like to be protected from mistakes
> they weren't aware they made, and far too few of our filesystem
> utilities provide that safety net.
> 
> A couple of users a year losing data like this is a couple of users
> too many. Especially when it would only take a couple of hours of
> your time to implement....
> 
> > So even thoug it might help in some cases I do not think that we
> > should go and change all file systems to do that as well, it would
> > not be very useful anyway.
> 
> Tell that to the next user that trashes their data because a
> filesystem tool simply assumed in correctly that it owned the block
> device.

I am not sure whether using a single file system for the
lifetime of the hardware is really the case, it seems unlikely to
me, but you have more experience than I do... But I am not talking
about remaking the file system hundreds of times a day, because once
is just enough to hit this.

mkfs.ext4 actually does have 'undo' functionality which can store
the changes made to the device on the file system itself. It is not
enabled by default, but exactly for this reason I've been thinking
of ways to make this default and possible delete the data when it's
not likely to be needed anymore (first mount ? write ?).

I was also thinking about checking /etc/fstab prior the file system
creation, this might rule out most of the false positives that
mkfs.xfs can generate I guess.

-Lukas


> 
> Cheers,
> 
> Dave.
> 

[-- Attachment #2: Type: text/plain, Size: 121 bytes --]

_______________________________________________
xfs mailing list
xfs@oss.sgi.com
http://oss.sgi.com/mailman/listinfo/xfs

^ permalink raw reply	[flat|nested] 27+ messages in thread

* Re: [PATCH] xfs_mkfs: wipe old signatures from the device
  2013-02-14 11:04                 ` Dave Chinner
@ 2013-02-14 14:48                   ` Martin Steigerwald
  -1 siblings, 0 replies; 27+ messages in thread
From: Martin Steigerwald @ 2013-02-14 14:48 UTC (permalink / raw)
  To: linux-btrfs
  Cc: Dave Chinner, Lukáš Czerner, Chris Murphy, Karel Zak,
	xfs, sandeen, Zach Brown

Am Donnerstag, 14. Februar 2013 schrieb Dave Chinner:
> > So I
> > think that it got to the point where users will usually use mkfs.xfs
> > -f all the time. And even if they did not and they would use a wrong
> > device they would probably get the same warning even for the device
> > they wanted to use in the first place.
> 
> I get a couple of queries a year from people saying they
> accidentally ran mkfs.ext4 on the wrong device and want to know if
> they can recover their XFS filesystem. The next question is usually
> "why didn't mkfs.ext4 warn me there was an existing filesystem on
> the device like mkfs.xfs does?".
> 
> That is why the "don't overwrite an existing filesystem by default"
> behaviour is important. Users like to be protected from mistakes
> they weren't aware they made, and far too few of our filesystem
> utilities provide that safety net.
> 
> A couple of users a year losing data like this is a couple of users
> too many. Especially when it would only take a couple of hours of
> your time to implement....
> 
> > So even thoug it might help in some cases I do not think that we
> > should go and change all file systems to do that as well, it would
> > not be very useful anyway.
> 
> Tell that to the next user that trashes their data because a
> filesystem tool simply assumed in correctly that it owned the block
> device.

Full ACK.

I always loved that mkfs.xfs asks in that case.

IMO its just sane to do so.

-- 
Martin 'Helios' Steigerwald - http://www.Lichtvoll.de
GPG: 03B0 0D6C 0040 0710 4AFA  B82F 991B EAAC A599 84C7

^ permalink raw reply	[flat|nested] 27+ messages in thread

* Re: [PATCH] xfs_mkfs: wipe old signatures from the device
@ 2013-02-14 14:48                   ` Martin Steigerwald
  0 siblings, 0 replies; 27+ messages in thread
From: Martin Steigerwald @ 2013-02-14 14:48 UTC (permalink / raw)
  To: linux-btrfs
  Cc: sandeen, xfs, Karel Zak, Zach Brown, Lukáš Czerner,
	Chris Murphy

Am Donnerstag, 14. Februar 2013 schrieb Dave Chinner:
> > So I
> > think that it got to the point where users will usually use mkfs.xfs
> > -f all the time. And even if they did not and they would use a wrong
> > device they would probably get the same warning even for the device
> > they wanted to use in the first place.
> 
> I get a couple of queries a year from people saying they
> accidentally ran mkfs.ext4 on the wrong device and want to know if
> they can recover their XFS filesystem. The next question is usually
> "why didn't mkfs.ext4 warn me there was an existing filesystem on
> the device like mkfs.xfs does?".
> 
> That is why the "don't overwrite an existing filesystem by default"
> behaviour is important. Users like to be protected from mistakes
> they weren't aware they made, and far too few of our filesystem
> utilities provide that safety net.
> 
> A couple of users a year losing data like this is a couple of users
> too many. Especially when it would only take a couple of hours of
> your time to implement....
> 
> > So even thoug it might help in some cases I do not think that we
> > should go and change all file systems to do that as well, it would
> > not be very useful anyway.
> 
> Tell that to the next user that trashes their data because a
> filesystem tool simply assumed in correctly that it owned the block
> device.

Full ACK.

I always loved that mkfs.xfs asks in that case.

IMO its just sane to do so.

-- 
Martin 'Helios' Steigerwald - http://www.Lichtvoll.de
GPG: 03B0 0D6C 0040 0710 4AFA  B82F 991B EAAC A599 84C7

_______________________________________________
xfs mailing list
xfs@oss.sgi.com
http://oss.sgi.com/mailman/listinfo/xfs

^ permalink raw reply	[flat|nested] 27+ messages in thread

* Re: [PATCH] xfs_mkfs: wipe old signatures from the device
  2013-02-14 11:04                 ` Dave Chinner
@ 2013-02-14 14:54                   ` Hugo Mills
  -1 siblings, 0 replies; 27+ messages in thread
From: Hugo Mills @ 2013-02-14 14:54 UTC (permalink / raw)
  To: Dave Chinner
  Cc: Lukáš Czerner, Chris Murphy, Karel Zak, xfs, sandeen,
	Zach Brown, linux-btrfs

[-- Attachment #1: Type: text/plain, Size: 2454 bytes --]

On Thu, Feb 14, 2013 at 10:04:23PM +1100, Dave Chinner wrote:
> On Thu, Feb 14, 2013 at 09:36:38AM +0100, Lukáš Czerner wrote:
> > On Thu, 14 Feb 2013, Chris Murphy wrote:
> > 
> > > Date: Thu, 14 Feb 2013 00:29:59 -0700
> > > From: Chris Murphy <lists@colorremedies.com>
> > > To: Dave Chinner <david@fromorbit.com>
> > > Cc: Karel Zak <kzak@redhat.com>, Lukáš Czerner <lczerner@redhat.com>,
> > >     xfs@oss.sgi.com, sandeen@redhat.com, Zach Brown <zabrown@redhat.com>,
> > >     linux-btrfs@vger.kernel.org
> > > Subject: Re: [PATCH] xfs_mkfs: wipe old signatures from the device

> > So I
> > think that it got to the point where users will usually use mkfs.xfs
> > -f all the time. And even if they did not and they would use a wrong
> > device they would probably get the same warning even for the device
> > they wanted to use in the first place.
> 
> I get a couple of queries a year from people saying they
> accidentally ran mkfs.ext4 on the wrong device and want to know if
> they can recover their XFS filesystem. The next question is usually
> "why didn't mkfs.ext4 warn me there was an existing filesystem on
> the device like mkfs.xfs does?".
> 
> That is why the "don't overwrite an existing filesystem by default"
> behaviour is important. Users like to be protected from mistakes
> they weren't aware they made, and far too few of our filesystem
> utilities provide that safety net.
> 
> A couple of users a year losing data like this is a couple of users
> too many. Especially when it would only take a couple of hours of
> your time to implement....
> 
> > So even thoug it might help in some cases I do not think that we
> > should go and change all file systems to do that as well, it would
> > not be very useful anyway.
> 
> Tell that to the next user that trashes their data because a
> filesystem tool simply assumed in correctly that it owned the block
> device.

   We had someone on IRC a day or two ago who had done exactly this.
They're not the only one -- I can recall seeing at least one other
person who managed to mkfs.btrfs on an existing filesystem.

   Hugo.

-- 
=== Hugo Mills: hugo@... carfax.org.uk | darksatanic.net | lug.org.uk ===
  PGP key: 515C238D from wwwkeys.eu.pgp.net or http://www.carfax.org.uk
  --- I am but mad north-north-west:  when the wind is southerly, I ---  
                       know a hawk from a handsaw.                       

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 828 bytes --]

^ permalink raw reply	[flat|nested] 27+ messages in thread

* Re: [PATCH] xfs_mkfs: wipe old signatures from the device
@ 2013-02-14 14:54                   ` Hugo Mills
  0 siblings, 0 replies; 27+ messages in thread
From: Hugo Mills @ 2013-02-14 14:54 UTC (permalink / raw)
  To: Dave Chinner
  Cc: sandeen, xfs, Karel Zak, Zach Brown, Lukáš Czerner,
	Chris Murphy, linux-btrfs


[-- Attachment #1.1: Type: text/plain, Size: 2454 bytes --]

On Thu, Feb 14, 2013 at 10:04:23PM +1100, Dave Chinner wrote:
> On Thu, Feb 14, 2013 at 09:36:38AM +0100, Lukáš Czerner wrote:
> > On Thu, 14 Feb 2013, Chris Murphy wrote:
> > 
> > > Date: Thu, 14 Feb 2013 00:29:59 -0700
> > > From: Chris Murphy <lists@colorremedies.com>
> > > To: Dave Chinner <david@fromorbit.com>
> > > Cc: Karel Zak <kzak@redhat.com>, Lukáš Czerner <lczerner@redhat.com>,
> > >     xfs@oss.sgi.com, sandeen@redhat.com, Zach Brown <zabrown@redhat.com>,
> > >     linux-btrfs@vger.kernel.org
> > > Subject: Re: [PATCH] xfs_mkfs: wipe old signatures from the device

> > So I
> > think that it got to the point where users will usually use mkfs.xfs
> > -f all the time. And even if they did not and they would use a wrong
> > device they would probably get the same warning even for the device
> > they wanted to use in the first place.
> 
> I get a couple of queries a year from people saying they
> accidentally ran mkfs.ext4 on the wrong device and want to know if
> they can recover their XFS filesystem. The next question is usually
> "why didn't mkfs.ext4 warn me there was an existing filesystem on
> the device like mkfs.xfs does?".
> 
> That is why the "don't overwrite an existing filesystem by default"
> behaviour is important. Users like to be protected from mistakes
> they weren't aware they made, and far too few of our filesystem
> utilities provide that safety net.
> 
> A couple of users a year losing data like this is a couple of users
> too many. Especially when it would only take a couple of hours of
> your time to implement....
> 
> > So even thoug it might help in some cases I do not think that we
> > should go and change all file systems to do that as well, it would
> > not be very useful anyway.
> 
> Tell that to the next user that trashes their data because a
> filesystem tool simply assumed in correctly that it owned the block
> device.

   We had someone on IRC a day or two ago who had done exactly this.
They're not the only one -- I can recall seeing at least one other
person who managed to mkfs.btrfs on an existing filesystem.

   Hugo.

-- 
=== Hugo Mills: hugo@... carfax.org.uk | darksatanic.net | lug.org.uk ===
  PGP key: 515C238D from wwwkeys.eu.pgp.net or http://www.carfax.org.uk
  --- I am but mad north-north-west:  when the wind is southerly, I ---  
                       know a hawk from a handsaw.                       

[-- Attachment #1.2: Digital signature --]
[-- Type: application/pgp-signature, Size: 828 bytes --]

[-- Attachment #2: Type: text/plain, Size: 121 bytes --]

_______________________________________________
xfs mailing list
xfs@oss.sgi.com
http://oss.sgi.com/mailman/listinfo/xfs

^ permalink raw reply	[flat|nested] 27+ messages in thread

* Re: [PATCH] xfs_mkfs: wipe old signatures from the device
  2013-02-14  8:36             ` Lukáš Czerner
@ 2013-02-14 17:25                 ` Eric Sandeen
  2013-02-14 17:25                 ` Eric Sandeen
  1 sibling, 0 replies; 27+ messages in thread
From: Eric Sandeen @ 2013-02-14 17:25 UTC (permalink / raw)
  To: Lukáš Czerner
  Cc: Chris Murphy, Dave Chinner, Karel Zak, xfs, Zach Brown, linux-btrfs

On 2/14/13 2:36 AM, Lukáš Czerner wrote:
> On Thu, 14 Feb 2013, Chris Murphy wrote:
> 
>> Date: Thu, 14 Feb 2013 00:29:59 -0700
>> From: Chris Murphy <lists@colorremedies.com>
>> To: Dave Chinner <david@fromorbit.com>
>> Cc: Karel Zak <kzak@redhat.com>, Lukáš Czerner <lczerner@redhat.com>,
>>     xfs@oss.sgi.com, sandeen@redhat.com, Zach Brown <zabrown@redhat.com>,
>>     linux-btrfs@vger.kernel.org
>> Subject: Re: [PATCH] xfs_mkfs: wipe old signatures from the device
>>
>>
>> On Feb 13, 2013, at 3:17 PM, Dave Chinner <david@fromorbit.com> wrote:
>>> it is the responsibility of filesystem
>>> tools to behave sanely, not for the rest of the world to have to
>>> work around the dangerous behaviour of a specific filesystems'
>>> toolset.
>>
>> I appreciate this, and in particular that mkfs.xfs doesn't nerf a file system without the use of -f; even an existing XFS file system. Considering most data loss is user induced, I'd appreciate it if other file systems's tools weren't so easily made belligerent by (hopefully temporarily) confused apes wearing pants.
>>
>> Chris Murphy
> 
> I would not be so optimistic about it. The reason being that there
> are almost _always_ old file system signatures on the device. So I
> think that it got to the point where users will usually use mkfs.xfs
> -f all the time. 

I know I do ;)  But as Dave points out, fs developers are odd ducks.

> And even if they did not and they would use a wrong
> device they would probably get the same warning even for the device
> they wanted to use in the first place.

I was thinking, as annoying as it might be, requiring the user to
use "-f $OLD_FS_TYPE" might require a bit more positive action
and cognition on the admin's part.

OTOH, that could get annoying, and break old scripts.  :)

-Eric

> So even thoug it might help in some cases I do not think that we
> should go and change all file systems to do that as well, it would
> not be very useful anyway.
> 
> -Lukas
> 


^ permalink raw reply	[flat|nested] 27+ messages in thread

* Re: [PATCH] xfs_mkfs: wipe old signatures from the device
@ 2013-02-14 17:25                 ` Eric Sandeen
  0 siblings, 0 replies; 27+ messages in thread
From: Eric Sandeen @ 2013-02-14 17:25 UTC (permalink / raw)
  To: Lukáš Czerner
  Cc: xfs, Karel Zak, Zach Brown, Chris Murphy, linux-btrfs

On 2/14/13 2:36 AM, Lukáš Czerner wrote:
> On Thu, 14 Feb 2013, Chris Murphy wrote:
> 
>> Date: Thu, 14 Feb 2013 00:29:59 -0700
>> From: Chris Murphy <lists@colorremedies.com>
>> To: Dave Chinner <david@fromorbit.com>
>> Cc: Karel Zak <kzak@redhat.com>, Lukáš Czerner <lczerner@redhat.com>,
>>     xfs@oss.sgi.com, sandeen@redhat.com, Zach Brown <zabrown@redhat.com>,
>>     linux-btrfs@vger.kernel.org
>> Subject: Re: [PATCH] xfs_mkfs: wipe old signatures from the device
>>
>>
>> On Feb 13, 2013, at 3:17 PM, Dave Chinner <david@fromorbit.com> wrote:
>>> it is the responsibility of filesystem
>>> tools to behave sanely, not for the rest of the world to have to
>>> work around the dangerous behaviour of a specific filesystems'
>>> toolset.
>>
>> I appreciate this, and in particular that mkfs.xfs doesn't nerf a file system without the use of -f; even an existing XFS file system. Considering most data loss is user induced, I'd appreciate it if other file systems's tools weren't so easily made belligerent by (hopefully temporarily) confused apes wearing pants.
>>
>> Chris Murphy
> 
> I would not be so optimistic about it. The reason being that there
> are almost _always_ old file system signatures on the device. So I
> think that it got to the point where users will usually use mkfs.xfs
> -f all the time. 

I know I do ;)  But as Dave points out, fs developers are odd ducks.

> And even if they did not and they would use a wrong
> device they would probably get the same warning even for the device
> they wanted to use in the first place.

I was thinking, as annoying as it might be, requiring the user to
use "-f $OLD_FS_TYPE" might require a bit more positive action
and cognition on the admin's part.

OTOH, that could get annoying, and break old scripts.  :)

-Eric

> So even thoug it might help in some cases I do not think that we
> should go and change all file systems to do that as well, it would
> not be very useful anyway.
> 
> -Lukas
> 

_______________________________________________
xfs mailing list
xfs@oss.sgi.com
http://oss.sgi.com/mailman/listinfo/xfs

^ permalink raw reply	[flat|nested] 27+ messages in thread

* Re: [PATCH] xfs_mkfs: wipe old signatures from the device
  2013-02-14 14:48                   ` Martin Steigerwald
@ 2013-02-14 18:35                     ` Eric Sandeen
  -1 siblings, 0 replies; 27+ messages in thread
From: Eric Sandeen @ 2013-02-14 18:35 UTC (permalink / raw)
  To: Martin Steigerwald
  Cc: linux-btrfs, Dave Chinner, Lukáš Czerner, Chris Murphy,
	Karel Zak, xfs, Zach Brown

On 2/14/13 8:48 AM, Martin Steigerwald wrote:
> Am Donnerstag, 14. Februar 2013 schrieb Dave Chinner:
>>> So I
>>> think that it got to the point where users will usually use mkfs.xfs
>>> -f all the time. And even if they did not and they would use a wrong
>>> device they would probably get the same warning even for the device
>>> they wanted to use in the first place.
>>
>> I get a couple of queries a year from people saying they
>> accidentally ran mkfs.ext4 on the wrong device and want to know if
>> they can recover their XFS filesystem. The next question is usually
>> "why didn't mkfs.ext4 warn me there was an existing filesystem on
>> the device like mkfs.xfs does?".
>>
>> That is why the "don't overwrite an existing filesystem by default"
>> behaviour is important. Users like to be protected from mistakes
>> they weren't aware they made, and far too few of our filesystem
>> utilities provide that safety net.
>>
>> A couple of users a year losing data like this is a couple of users
>> too many. Especially when it would only take a couple of hours of
>> your time to implement....
>>
>>> So even thoug it might help in some cases I do not think that we
>>> should go and change all file systems to do that as well, it would
>>> not be very useful anyway.
>>
>> Tell that to the next user that trashes their data because a
>> filesystem tool simply assumed in correctly that it owned the block
>> device.
> 
> Full ACK.
> 
> I always loved that mkfs.xfs asks in that case.
> 
> IMO its just sane to do so.

I just sent a patch to do so for btrfs-progs, FWIW.  :)

-Eric



^ permalink raw reply	[flat|nested] 27+ messages in thread

* Re: [PATCH] xfs_mkfs: wipe old signatures from the device
@ 2013-02-14 18:35                     ` Eric Sandeen
  0 siblings, 0 replies; 27+ messages in thread
From: Eric Sandeen @ 2013-02-14 18:35 UTC (permalink / raw)
  To: Martin Steigerwald
  Cc: xfs, Karel Zak, Zach Brown, Lukáš Czerner,
	Chris Murphy, linux-btrfs

On 2/14/13 8:48 AM, Martin Steigerwald wrote:
> Am Donnerstag, 14. Februar 2013 schrieb Dave Chinner:
>>> So I
>>> think that it got to the point where users will usually use mkfs.xfs
>>> -f all the time. And even if they did not and they would use a wrong
>>> device they would probably get the same warning even for the device
>>> they wanted to use in the first place.
>>
>> I get a couple of queries a year from people saying they
>> accidentally ran mkfs.ext4 on the wrong device and want to know if
>> they can recover their XFS filesystem. The next question is usually
>> "why didn't mkfs.ext4 warn me there was an existing filesystem on
>> the device like mkfs.xfs does?".
>>
>> That is why the "don't overwrite an existing filesystem by default"
>> behaviour is important. Users like to be protected from mistakes
>> they weren't aware they made, and far too few of our filesystem
>> utilities provide that safety net.
>>
>> A couple of users a year losing data like this is a couple of users
>> too many. Especially when it would only take a couple of hours of
>> your time to implement....
>>
>>> So even thoug it might help in some cases I do not think that we
>>> should go and change all file systems to do that as well, it would
>>> not be very useful anyway.
>>
>> Tell that to the next user that trashes their data because a
>> filesystem tool simply assumed in correctly that it owned the block
>> device.
> 
> Full ACK.
> 
> I always loved that mkfs.xfs asks in that case.
> 
> IMO its just sane to do so.

I just sent a patch to do so for btrfs-progs, FWIW.  :)

-Eric


_______________________________________________
xfs mailing list
xfs@oss.sgi.com
http://oss.sgi.com/mailman/listinfo/xfs

^ permalink raw reply	[flat|nested] 27+ messages in thread

* Re: [PATCH] xfs_mkfs: wipe old signatures from the device
  2013-02-14 17:25                 ` Eric Sandeen
  (?)
@ 2013-02-14 19:08                 ` Chris Murphy
  -1 siblings, 0 replies; 27+ messages in thread
From: Chris Murphy @ 2013-02-14 19:08 UTC (permalink / raw)
  To: Eric Sandeen
  Cc: xfs, Karel Zak, Zach Brown, Lukáš Czerner, linux-btrfs


On Feb 14, 2013, at 10:25 AM, Eric Sandeen <sandeen@redhat.com> wrote:
> 
> I was thinking, as annoying as it might be, requiring the user to
> use "-f $OLD_FS_TYPE" might require a bit more positive action
> and cognition on the admin's part.
> 
> OTOH, that could get annoying, and break old scripts.  :)


Yes, it's possible to get carried away with this: An "are you sure" prompt that requires typing "yes"; or even more deliciously irritating, only accepts as positive:

"primateconfirmspreviousfilesystemdestructionwontsubsequentlyaskaboutdatarecovery"

Way, way more people will copy/paste that from a list or man entry, than acquire muscle memory for -f.


Chris Murphy
_______________________________________________
xfs mailing list
xfs@oss.sgi.com
http://oss.sgi.com/mailman/listinfo/xfs

^ permalink raw reply	[flat|nested] 27+ messages in thread

* Re: [PATCH] xfs_mkfs: wipe old signatures from the device
  2013-02-14 11:45           ` Dave Howorth
@ 2013-02-14 19:17             ` Eric Sandeen
  0 siblings, 0 replies; 27+ messages in thread
From: Eric Sandeen @ 2013-02-14 19:17 UTC (permalink / raw)
  To: Dave Howorth; +Cc: xfs

On 2/14/13 5:45 AM, Dave Howorth wrote:
> Dave Chinner wrote:
>> IOWs, it is the responsibility of the filesystem tools to correctly
>> identify the filesystem being operated on, and not to
>> modify/trash/recover anything unless specifically directed by the
>> user.  When a filesystem tool gets it wrong, then that specific tool
>> needs to be fixed.  i.e. it is the responsibility of filesystem
>> tools to behave sanely, not for the rest of the world to have to
>> work around the dangerous behaviour of a specific filesystems'
>> toolset.
> 
> As an average Joe user, I started to agree with this, but then as a
> developer I had second thoughts. It can't be right that every filesystem
> tool has to have code to recognize every other type of filesystem; that
> just doesn't scale. So each tool would need to call some API, which I

Yep - it's called libblkid, it's very easy to use for this purpose.
xfsprogs already does, and I just sent a patch for btrfs-progs as well.

So libblkid contains all the smarts, really, and it's not a code duplication
problem.

> suppose would need to access some kernel code that iterated for every
> filesystem type the kernel was configured to handle, or knew historically.

Nah, it doesn't matter what the running kernel knows about, IMHO, just what
is recognized on the disk at hand.

-Eric

> And then we have identical code in every tool, and that code is not
> serving the tool's primary purpose, so maybe it should be factored out
> on the one-tool-one-job philosophy. So perhaps there should be a single
> tool that tells what filesystem type is present on a device, which
> everybody runs before mkfs. Oh wait, df -T or other utilities already do
> that.
> 
> So I'm not sure the issue is black and white. As an average Joe, I
> expect mkfs to trash whatever I give it, so I'm pretty careful to check
> what is there first. And if I expected to be overwriting an existing
> filesystem and I did it often enough to know about the mkfs.xfs
> behaviour, I suppose I would always invoke it with the -f flag.
> Consistency among the various flavours of mkfs would be nice, though.
> 
> _______________________________________________
> xfs mailing list
> xfs@oss.sgi.com
> http://oss.sgi.com/mailman/listinfo/xfs
> 

_______________________________________________
xfs mailing list
xfs@oss.sgi.com
http://oss.sgi.com/mailman/listinfo/xfs

^ permalink raw reply	[flat|nested] 27+ messages in thread

end of thread, other threads:[~2013-02-14 19:17 UTC | newest]

Thread overview: 27+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2013-02-12 11:06 [PATCH] xfs_mkfs: wipe old signatures from the device Lukas Czerner
2013-02-12 11:31 ` Karel Zak
2013-02-12 11:58   ` Lukáš Czerner
2013-02-12 20:27 ` Dave Chinner
2013-02-13  8:01   ` Karel Zak
2013-02-13 10:41     ` Lukáš Czerner
2013-02-13 12:16       ` Karel Zak
2013-02-13 12:16         ` Karel Zak
2013-02-13 22:17         ` Dave Chinner
2013-02-13 22:17           ` Dave Chinner
2013-02-14  7:29           ` Chris Murphy
2013-02-14  7:29             ` Chris Murphy
2013-02-14  8:36             ` Lukáš Czerner
2013-02-14 11:04               ` Dave Chinner
2013-02-14 11:04                 ` Dave Chinner
2013-02-14 12:28                 ` Lukáš Czerner
2013-02-14 14:48                 ` Martin Steigerwald
2013-02-14 14:48                   ` Martin Steigerwald
2013-02-14 18:35                   ` Eric Sandeen
2013-02-14 18:35                     ` Eric Sandeen
2013-02-14 14:54                 ` Hugo Mills
2013-02-14 14:54                   ` Hugo Mills
2013-02-14 17:25               ` Eric Sandeen
2013-02-14 17:25                 ` Eric Sandeen
2013-02-14 19:08                 ` Chris Murphy
2013-02-14 11:45           ` Dave Howorth
2013-02-14 19:17             ` Eric Sandeen

This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.