xfs
[Top] [All Lists]

Re: Bugreport - not really important

To: GCS <gcs@xxxxxxxxxxxxxxxx>
Subject: Re: Bugreport - not really important
From: "Martin K. Petersen" <mkp@xxxxxxxxxxxxx>
Date: 20 Mar 2001 08:55:22 -0500
Cc: Tom Duffy <tduffy@xxxxxxxxxxxx>, <linux-xfs@xxxxxxxxxxx>
In-reply-to: <Pine.LNX.4.30.0103200223470.2403-100000@dbear.engr.sgi.com>
Organization: Linuxcare, Inc.
References: <Pine.LNX.4.30.0103200223470.2403-100000@dbear.engr.sgi.com>
Sender: owner-linux-xfs@xxxxxxxxxxx
User-agent: Gnus/5.0808 (Gnus v5.8.8) XEmacs/21.1 (Canyonlands)
>>>>> "Tom" == Tom Duffy <tduffy@xxxxxxxxxxxx> writes:

Tom> what I am surprised about is that xfs did not replace the magic
Tom> number that tells the kernel and other tools what type of fs it
Tom> is.  otherwise, the reiser tools do not verify this number (or
Tom> assume it could be corrupted).

The problem here is that every fs puts its superblock a different
place.  XFS has it on block 0, and reiserfs' is 64K from the beginning
of the device.

It so happens that in your case XFS doesn't write anything on that
position.  Consequently, the reiser superblock is intact after
mkfs.xfs.

There's really no smart way to avoid this as that would require
knowledge of all file systems on the planet.  Some may have their sb
at the middle or the end of the device etc.  And dd'ing zeroes to the
entire device will take forever.

I guess we could blast - say 70KB - of NULL chars to the start of the
partition.  As far as I can tell, that should get rid of any fs that
Linux currently supports (Unless they try and use backup copies in
that case.  I guess we'll have to experiment a bit).

Nathan, comments?

-- 
Martin K. Petersen, Principal Linux Consultant, Linuxcare, Inc.
mkp@xxxxxxxxxxxxx, http://www.linuxcare.com/
SGI XFS for Linux Developer, http://oss.sgi.com/projects/xfs/

<Prev in Thread] Current Thread [Next in Thread>