Some additional info -- and attempting to cast a wider net on the CC: I do not see the long symlink corruption with mount -o data=writeback and we've now seen a couple cases where the symlink corruption does not require a umount... Arthur On Fri, Oct 24, 2008 at 11:37:34AM -0700, Arthur Jones wrote: > Hi All, I'm seeing slow symlink corruption on ext3 on linux-2.6.27, > yesterday's linux-2.6 git tree and 2.6.9 RHEL4.7. I.e. every kernel > I've tried I see this effect. To reproduce this, I need: > > * 250MB + tar file in memory (tmpfs or in the buffer cache) > * long symlinks in the tar file (over 60 characters) > * umount immediately after untarring > > What I see is that the symlinks are corrupted, e.g.: > > # ls -l etc/vmware-vix-disklib > etc/vmware-vix-disklib -> ??f > > fsck shows: > > Symlink /etc/vmware-vix-disklib (inode #16454) is invalid. > > Debugfs shows: > > debugfs: stat <16454> > Inode: 16454 Type: symlink Mode: 0777 Flags: 0x0 Generation: 1431972005 > User: 0 Group: 0 Size: 65 > File ACL: 0 Directory ACL: 0 > Links: 1 Blockcount: 8 > Fragment: Address: 0 Number: 0 Size: 0 > ctime: 0x4900ac69 -- Thu Oct 23 09:55:05 2008 > atime: 0x4900ac84 -- Thu Oct 23 09:55:32 2008 > mtime: 0x4900ac69 -- Thu Oct 23 09:55:05 2008 > BLOCKS: > (0):56034 > TOTAL: 1 > > I'm still tracking down exactly what's going on. Anyone seen > anything like this before? ext2 does not show this effect (I've > not tried ext4). It happens when the backing block device is > a SATA drive or flash. > > Thanks, > > Arthur -- To unsubscribe from this list: send the line "unsubscribe linux-ext4" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
