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 for Android: free password hash cracker in your pocket

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

Date:	Mon, 10 Feb 2014 11:47:00 +0800
From:	Zheng Liu <gnehzuil.liu@...il.com>
To:	Ian Nartowicz <claws@...towicz.co.uk>
Cc:	linux-ext4@...r.kernel.org
Subject: Re: inline_data feature

On Sun, Feb 09, 2014 at 03:45:12PM +0000, Ian Nartowicz wrote:
> 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.

I'd appreciate your testing.

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

That would be great if you can provide some steps to reproduce this
issue.  I write a simple script to try to reproduce it, but I couldn't
hit the problem.  Am I missing something?

  #!/bin/bash
  
  mkdir test
  cd test
  filename="ALL-That-You-Can't-Leave-Behind.m3u"
  
  echo "hello" > $filename
  ln -s $filename symlinkfile
  readlink symlinkfile
  
  newdir="data/cd"
  mkdir -p $newdir
  cp -d symlinkfile $newdir
  readlink $newdir/symlinkfile
  
Thanks,
                                                - Zheng
--
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