On Fri, 20 Jul 2007 16:37:09 +0100
Alan Cox <alan@xxxxxxxxxxxxxxxxxxx> wrote:
> Ok try booting with
>
> libata.ignore_hpa=1
I used that option:
fraga@abusar ~$ dmesg|grep hpa
Kernel command line: auto BOOT_IMAGE=linux rw root=902 panic=5 libata.ignore_hpa=1
and tried to makereiserfs again, but got the same results:
Guessing about desired format.. Kernel 2.6.22 is running.
Format 3.6 with standard journal
Count of blocks on the device: 19410528
Number of blocks consumed by mkreiserfs formatting process: 8804
Blocksize: 4096
Hash function used to sort names: "r5"
Journal Size 8193 blocks (first block 18)
Journal Max transaction length 1024
inode generation number: 0
19410528 x 4 = 77642112
which is higher than
Used Dev Size : 77642048 (74.05 GiB 79.51 GB)
The "solution" was to reduce 64K from the reiser partition, as
suggested by Neil Brown. This way the raid stopped to complain.
But I really don't know why mkreiserfs is creating a filesystem
with 64k more than allowed by the device... maybe a bug in mkreiserfs?
The strange is that it didn't happen with the OLD IDE
drivers... could it be a pata_via bug?
To determine if it is mkreiserfs' fault I used mke2fs just
to see if it will create the same number of blocks as reiserfs:
fraga@abusar ~$ sudo mke2fs /dev/sda2
mke2fs 1.19, 13-Jul-2000 for EXT2 FS 0.5b, 95/08/09
Filesystem label=
OS type: Linux
Block size=4096 (log=2)
Fragment size=4096 (log=2)
9715712 inodes, 19410536 blocks
970526 blocks (5.00%) reserved for the super user
First data block=0
593 block groups
32768 blocks per group, 32768 fragments per group
16384 inodes per group
Superblock backups stored on blocks:
32768, 98304, 163840, 229376, 294912, 819200, 884736, 1605632, 2654208,
4096000, 7962624, 11239424
Writing inode tables: done
Writing superblocks and filesystem accounting information: done
***
As you can see it created 19410536 blocks (19410536 x 4 =
77642144, exactly as mkreiserfs did).
So I suppose it's a bug in some other place.
Or mdadm is determining the incorrect size of the device,
64K less than the real size? Just for your convenience, mdadm returns:
Array Size : 77642048 (74.05 GiB 79.51 GB)
Used Dev Size : 77642048 (74.05 GiB 79.51 GB)
and mkreiserfs, mke2fs etc return 77642144. In other words, 64K
more. Which one is correct? mkreiserfs/mke2fs or mdadm?
According Neil Brown, mdadm is correct and we don't know why
mkreiserfs is creating a filesystem 64k larger than the device... so it
could be a pata_via bug... is there any other test I can do to
get rid of the possibility of a pata_via bug? If you need i can apply
patches in the kernel or activate some other option.
And it seems that mdadm's method to determine the size of the
partition is different from mkreiserfs/mke2fs etc, right?
Thank you!
--
Linux 2.6.22: Holy Dancing Manatees, Batman!
http://www.lastfm.pt/user/danielfraga
http://u-br.net
Marilyn Manson - "Cruci-Fiction in Space" (Holy Wood (In the Shadow of
the Valley of Death) - 2000)
-
To unsubscribe from this list: send the line "unsubscribe linux-ide" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
