[Top] [All Lists]

Re: Bugreport - not really important

To: linux-xfs@xxxxxxxxxxx
Subject: Re: Bugreport - not really important
From: GCS <gcs@xxxxxxxxxxxxxxxx>
Date: Tue, 20 Mar 2001 12:54:44 +0100
In-reply-to: Tom Duffy wrote on K, MÁR 20, 2001 at 02:29:30 -0800:
References: <20010320104356.A14454@xxxxxxxxxxxxxxxx> <Pine.LNX.4.30.0103200223470.2403-100000@xxxxxxxxxxxxxxxxxx>
Sender: owner-linux-xfs@xxxxxxxxxxx
User-agent: Mutt/1.3.15i


On K, MÁR 20, 2001 at 02:29:30 -0800, Tom Duffy wrote:

> xfs will not trash the disk when it "formats" it.  this is most likely
> what is happening.  since xfs is lazy in its allocation and use of disk
> space, it probably did not blow away the reiser data structures allowing
> you to still mount it as reiser.
 I think XFS should do it, or things like this will happen. I know that XFS
dinamicaly allocate more inodes as there is a need. I like this idea to being
lazy in this way. But do you know if it happens in the opposite direction?
Let's say I create a lot of file, XFS allocates a lot of inodes which take
a considerable amount of disk space. Then I delete my million numbers of files,
and tries to save a big file. Just to realize I have a lot of inodes for
nothing, but does not have enough space for the file itself. What does XFS
do in this case? Does it delete some inode blocks, or not?

> when you ext2 formatted it, it went through and allocated ext2 inodes and
> such and copies of the superblock throughout the disk killing any chance
> of reiser being able to mount it.
 Sure, mkfs.ext2 took more time.

> what I am surprised about is that xfs did not replace the magic number
> that tells the kernel and other tools what type of fs it is.  otherwise,
> the reiser tools do not verify this number (or assume it could be
> corrupted).
 I think it is more XFS than ReiserFS. At mount time ReiserFS print some
debug information, and it said 'clean mount' -> no problems. Thus I think the
magic number is not changed by XFS.

> anyways, the best way to clean a partition is
> dd if=/dev/zero of=/dev/hd[letter][number]
 Sure, but specify bs=16384 (or depends on your amount of memory; at least
my test show when copying a 4Gb slice, it makes things faster). :-)

> enough times that even the FBI cannot recover your data.
 One is enough isn't it?

Thanks, Laszlo

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