Hi!
> Ok, this ext4 filesystem does _not_ have easy life: it is in usb envelope, I
> wanted
> to use it as a root filesystem, and it is connected to OLPC-1.75, running
> some kind
> of linux-3.0 kernels.
>
> So power disconnects are common, and even during regular reboot, I hear disk
> doing
> emergency parking.
>
> I don't know how barriers work over USB...
>
> Plus the drive has physical bad blocks, but I attempted to mark them with
> fsck -c.
>
> OTOH, it is just a root filesystem... and nothing above should prevent
> correct operation
> (right?)
>
> On last mount, it remounted itself read-only, so there's time for fsck, I
> guess...
>
> But I believe this means I am going to lose all the data on the filesystem,
> right?
It looks like the filesystem contains _way_ too many 0xffff's:
Inode 655221 has compression flag set on filesystem without compression
support. Clear<y>? yes
Inode 655221 has INDEX_FL flag set but is not a directory.
Clear HTree index<y>? yes
Inode 655221 should not have EOFBLOCKS_FL set (size 18446744073709551615, lblk
-1)
Clear<y>? yes
Inode 655221, i_size is 18446744073709551615, should be 0. Fix<y>? yes
Inode 655221, i_blocks is 281474976710655, should be 0. Fix<y>? yes
Inode 655222 is in use, but has dtime set. Fix<y>? yes
Inode 655222 has imagic flag set. Clear<y>? yes
Inode 655222 has a extra size (65535) which is invalid
Fix<y>? yes
Inode 655222 has compression flag set on filesystem without compression
support. Clear<y>? yes
Inode 655222 has INDEX_FL flag set but is not a directory.
Clear HTree index<y>? yes
Inode 655222 should not have EOFBLOCKS_FL set (size 18446744073709551615, lblk
-1)
Clear<y>?
I saved beggining of the filesystem using cat /dev/sdc4 | gzip -9 - >
/dev/sda3, but
then ran out of patience. So there may be something for analysis, but...
Any ideas?
Pavel
--
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures)
http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
