Sorry, I did said, but I used dd to zero part of the device:
dev is /dev/sda1 (20GB)
# dd if=/dev/zero bs=1M count=1k > /dev/sda1
# echo y | mkfs.jfs /dev/sda1
I though that the first 1GB would be enogh... but no ... :(
Tried first with 100M, then 1GB, and then 10GB, on the same device ... same
The device is a 'partition' on a SAN array from compaq/hp. It is not used for
I am using kernel 2.4.23, slackware 9.1, dual P4, 4GB RAM
On Mon, Feb 23, 2004 at 05:13:32AM -0600, Ivan Kocher wrote:
Yesterday I was hit by a nasty bug ...
I tried to change the filesystem of a couple machines from XFS to JFS,
so compiled kernel 2.4.23 with XFS (patch) and JFS. Once the jfs root
partition was up, it booted, and xfs "tried" to repair the partition. I
booted using my default setup and later after remaking all again using
init=/bin/bash rw, and even later init=/bin/bash ro
In the first two cases cases, xfs tried its "repair", teling that it
recovered the journal... :( trashing the fs.
When I booted in the third case, (ro) no problem...
I wonder ... does xfs has some check for some magic in there? I tried
in all machines, and in all it damaged the mounted / jfs fs ...
sounds like mkfs.jfs is not zeroing enough of the device prior to
writing its fs. particularly block zero where the XFS superblock
lives. (some mkfs avoid zeroing this due to quirky partitioning setups
on some architectures, notably Suns).
dd if=/dev/zero of=/dev/dev_being_mkfsed bs=512 count=100
prior to running mkfs. that should zero out enough to prevent any
previous fs from being detected.
Also, will there ever be a xfs patch for 2.4.24?? I know 2.4.25 has
use the 2.4.23 patches, nothing changed in 2.4.24 that would affect
it... but for some reason I am having problems with a qlogic 2312 board
with 2.4.25 ... :( so I was thinking on testing 2.4.24 ... ???
apply the 2.4.23 split patches, all work and apply fine (except -misc,
which you don't generally need anyway).