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
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?