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
next prev parent 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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).