linux-ext4 - Re: Possible ext4 corruption

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: <1236736137.16191.25.camel@kulgan.wumi.org.au>
Date:	Wed, 11 Mar 2009 12:18:57 +1030
From:	Kevin Shanahan <kmshanah@...b.org.au>
To:	Andreas Dilger <adilger@....com>
Cc:	Theodore Tso <tytso@....edu>, Eric Sandeen <sandeen@...hat.com>,
	linux-ext4@...r.kernel.org
Subject: Re: Possible ext4 corruption - ACL related?

On Wed, 2009-03-11 at 12:13 +1030, Kevin Shanahan wrote:
> It looks like there is still a problem there, even after fsck has done
> it's cleanup.
> 
> Last night I got:
> 
>   getfattr: apps/Gestalt.Net/SetupCD/program\040files/Business\040Objects/Common/3.5/bin/RptControllers.dll: Input/output error
> 
> And syslog shows:
> 
>   Mar 11 00:06:01 hermes /USR/SBIN/CRON[26947]: (root) CMD (   /usr/local/bin/rsync-backup-all.sh)
>   Mar 11 00:06:24 hermes kernel: attempt to access beyond end of device
>   Mar 11 00:06:24 hermes kernel: dm-0: rw=0, want=946232834916360, limit=2147483648
>   Mar 11 00:06:24 hermes kernel: attempt to access beyond end of device
>   Mar 11 00:06:24 hermes kernel: dm-0: rw=0, want=946232834916360, limit=2147483648
> 
> hermes:~# getfattr /srv/samba/local/apps/Gestalt.Net/SetupCD/program\ files/Business\ Objects/Common/3.5/bin/RptControllers.dll 
> getfattr: /srv/samba/local/apps/Gestalt.Net/SetupCD/program\040files/Business\040Objects/Common/3.5/bin/RptControllers.dll: Input/output error
> 
> hermes:~# debugfs /dev/dm-0
> debugfs 1.41.3 (12-Oct-2008)
> debugfs:  stat "local/apps/Gestalt.Net/SetupCD/program files/Business Objects/Common/3.5/bin/RptControllers.dll"
> 
> Inode: 875   Type: FIFO    Mode:  0611   Flags: 0xb3b9c185
> Generation: 3690868    Version: 0x9d36b10d
> User: 868313917   Group: -1340283792   Size: 0
> File ACL: 0    Directory ACL: 0
> Links: 1   Blockcount: 0
> Fragment:  Address: 0    Number: 0    Size: 0
> ctime: 0x0742afc4 -- Sun Nov 11 06:51:24 1973
> atime: 0x472a2311 -- Fri Nov  2 05:33:45 2007
> mtime: 0x80c59881 -- Fri Jun 18 09:51:21 2038
> Size of extra inode fields: 4
> BLOCKS:
> 
> debugfs:  imap "local/apps/Gestalt.Net/SetupCD/program files/Business Objects/Common/3.5/bin/RptControllers.dll"
> Inode 875 is part of block group 0
> 	located at block 343, offset 0x0a00
> 
> hermes:~# dd if=/dev/dm-0 of=block-343.dump bs=4k skip=343 count=1
> 1+0 records in
> 1+0 records out
> 4096 bytes (4.1 kB) copied, 3.6316e-05 s, 113 MB/s
> 
> "strings block-343.dump" doesn't show anything obvious to me about where
> the data came from, but I guess the concern would be whether fsck didn't
> pick this up or maybe the corruption returned very quickly for some
> reason.

Oh, by the way:

hermes:~# ls -l /srv/samba/local/apps/Gestalt.Net/SetupCD/program\ files/Business\ Objects/Common/3.5/bin/RptControllers.dll 
prwS--x--t 1 868313917 2954683504 0 1902-05-13 03:23 /srv/samba/local/apps/Gestalt.Net/SetupCD/program files/Business Objects/Common/3.5/bin/RptControllers.dll

I guess this is what Andreas meant by "turning a pile of manure into
neatly organized fertilizer" :)

Cheers,
Kevin.


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