linux-ext4 - Re: inline

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <loom.20140209T163201-264@post.gmane.org>
Date:	Sun, 9 Feb 2014 15:45:12 +0000 (UTC)
From:	Ian Nartowicz <claws@...towicz.co.uk>
To:	linux-ext4@...r.kernel.org
Subject: Re: inline_data feature

Ian Nartowicz <claws <at> nartowicz.co.uk> writes:

> 
> I have been trying to test the inline_data feature of EXT4.  I am using
> kernel 3.9.5 and have compiled e2fsprogs from the pu branch.  I am able to
> set the feature and apparently to use the filesystem, but I get a lot of
> warnings from the kernel and fsck reports several errors and then crashes.
> 
> Typical kernel warnings from dmesg:
> EXT4-fs warning (device sda10): ext4_rmdir:2714: empty directory has too
> many links (9)
> EXT4-fs error (device sda10): empty_inline_dir:1650: inode #26263: block
> 1924: comm pool: bad entry in directory: directory entry across range -
> offset=40(40), inode=26270, rec_len=8020, name_len=2
> EXT4-fs warning (device sda10): empty_inline_dir:1657: bad inline directory
> (dir #26263) - inode 26270, rec_len 8020, name_len 2inline size 60
> 
> Data does appear to be correctly written and read from the filesystem
> without corruption.  Small directories appear with size 60 bytes or 132
> bytes rather than 4.1kB so everything seems to work.
> 
> --
> To unsubscribe from this list: send the line "unsubscribe linux-ext4" in
> the body of a message to majordomo <at> vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
> 
> 

I have built with the latest patchset and fsck is now a happy bunny, at
least on my first pass.

However there is a different problem, possibly not with fsck.  For my tests
I copied the contents of /home onto the new partition.  fsck reports, and
other utilities confirm, that symlinks with targets of 60 characters or
longer were corrupted by the copy.  For example, a truncated symlink:
All That You Can't Leave Behind.m3u -> /data/cd/U2/All That You Can't Leave
Behind/playlist.flac.m

If I create the same symlink with ln, it appears OK until I unmount and
mount the partition, then it shows truncated.  fsck doesn't like it but is
unable to correct it.

--ian

--
To unsubscribe from this list: send the line "unsubscribe linux-ext4" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html