Re: Possible ext4 corruption - ACL related?

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



Kevin Shanahan wrote:
> Hi,
> 
> I think we have some minor corruption happening with a new (about two
> weeks old) ext4 file system. Our backup script spat out bunch of errors
> last night while trying to read the file ACLs:
> 
> getfacl: apps/Gestalt.Net/SetupCD/program\040files/Business\040Objects/Common/3.5/bin/Cdo32sv.dll: Input/output error
> getfacl: apps/Gestalt.Net/SetupCD/program\040files/Business\040Objects/Common/3.5/bin/U3520chs.dll: Input/output error
> getfacl: apps/Gestalt.Net/SetupCD/program\040files/Business\040Objects/Common/3.5/bin/ReportRenderer.dll: Input/output error
> getfacl: apps/Gestalt.Net/SetupCD/program\040files/Business\040Objects/Common/3.5/bin/ParameterDesigner.dll: Input/output error
> ...
> 
> And in syslog I see these warnings from the kernel:
> 
> Mar 10 00:06:01 hermes /USR/SBIN/CRON[10875]: (root) CMD (   /usr/local/bin/rsync-backup-all.sh)
> Mar 10 00:06:24 hermes kernel: init_special_inode: bogus i_mode (53253)
> Mar 10 00:06:24 hermes kernel: attempt to access beyond end of device
> Mar 10 00:06:24 hermes kernel: dm-0: rw=0, want=1312475392770056, limit=2147483648
> Mar 10 00:06:25 hermes kernel: attempt to access beyond end of device
> Mar 10 00:06:25 hermes kernel: dm-0: rw=0, want=1312475392770056, limit=2147483648
> 
> The filesystem is still in use (and working okay, AFAICT), but I'll need
> to fsck this tonight. Is there any useful data I can gather from the fs
> before (or while) I do that which might help track down the cause?

an e2image of the filesystem before fsck might help, and be sure to save
fsck output.

Were there other interesting messages before or after the above?

If you try a manual getfacl of the above files do you still get the error?

> This system has been running 2.6.29-rc6 (x86_64) since this filesystem
> was created. I did a quick scan of the ext4 commits since then, but none
> of them obviously address this unless maybe it's related to 7ce9d5d -
>     "ext4: fix ext4_free_inode() vs. ext4_claim_inode() race"

Probably not; that one led to incorrect counters, but I did not see
serious corruption with it ...

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

[Index of Archives]     [Reiser Filesystem Development]     [Ceph FS]     [Kernel Newbies]     [Security]     [Netfilter]     [Bugtraq]     [Linux FS]     [Yosemite National Park]     [MIPS Linux]     [ARM Linux]     [Linux Security]     [Linux RAID]     [Samba]     [Device Mapper]     [Linux Media]

  Powered by Linux