All of lore.kernel.org
 help / color / mirror / Atom feed
From: Theodore Tso <tytso@mit.edu>
To: Christoph Hellwig <hch@infradead.org>
Cc: Erik Mouw <mouw@nl.linux.org>,
	Sachin Gaikwad <sachin.kernel@gmail.com>,
	Jim Cromie <jim.cromie@gmail.com>,
	kernel learner <kernellearner@gmail.com>,
	linux-fsdevel@vger.kernel.org, kernelnewbies@nl.linux.org
Subject: Re: Upgrading datastructures between different filesystem versions
Date: Fri, 28 Sep 2007 15:47:24 -0400	[thread overview]
Message-ID: <20070928194723.GI8688@thunk.org> (raw)
In-Reply-To: <20070928133146.GA9139@infradead.org>

On Fri, Sep 28, 2007 at 02:31:46PM +0100, Christoph Hellwig wrote:
> On Fri, Sep 28, 2007 at 03:11:00PM +0200, Erik Mouw wrote:
> > There are however ways to confuse it: if you reformat an ext3
> > filesystem to reiserfs (version 3), mounting that filesystem without
> > "-t reiserfs" will trick mount(8) into mounting it as an ext3
> > filesystem (which will usually fail). This is because the ext3
> > superblocks lives at offset 0x400, and the reiserfs superblock at
> > 0x8000. When you format a partition as reiserfs, it will not erase old
> > ext3 superblocks. Before looking for a reiserfs superblock, mount(8)
> > first looks for an ext3 superblock. The old ext3 superblock wasn't
> > erased, but usually most of the other ext3 structures are and so
> > mount(8) will fail to mount the filesystem. Don't know if this
> > particular "bug" is still there, but it has bitten me in the past.
> 
> This is easy to fix, though.  Quoting mkfs.xfs:
> 
> 	/*
>          * 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.
> 	 */
> 	buf = libxfs_getbuf(xi.ddev, 0, BTOBB(WHACK_SIZE));
> 	bzero(XFS_BUF_PTR(buf), WHACK_SIZE);
> 	libxfs_writebuf(buf, LIBXFS_EXIT_ON_FAILURE);
> 	libxfs_purgebuf(buf);

Ext3 does something similar, zapping space at the beginning AND the
end of the partition (because the MD superblocks are at the end).
It's just a misfeature of reiserfs's mkfs that it doesn't do this.

							- Ted

  reply	other threads:[~2007-09-28 19:47 UTC|newest]

Thread overview: 9+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2007-09-25 15:27 Upgrading datastructures between different filesystem versions kernel learner
2007-09-26  5:40 ` Jim Cromie
2007-09-26 16:17   ` Andreas Dilger
2007-09-26 23:29     ` Sachin Gaikwad
2007-09-27  0:53       ` Theodore Tso
2007-09-28 13:11       ` Erik Mouw
2007-09-28 13:31         ` Christoph Hellwig
2007-09-28 19:47           ` Theodore Tso [this message]
2007-09-29  9:05             ` Christoph Hellwig

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20070928194723.GI8688@thunk.org \
    --to=tytso@mit.edu \
    --cc=hch@infradead.org \
    --cc=jim.cromie@gmail.com \
    --cc=kernellearner@gmail.com \
    --cc=kernelnewbies@nl.linux.org \
    --cc=linux-fsdevel@vger.kernel.org \
    --cc=mouw@nl.linux.org \
    --cc=sachin.kernel@gmail.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
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.