[opensuse] xfs error won't repair
I have a /home partition using luks on xfs I've got two little files that barfed up errors while running a backup. Any attempt to access these files results in an error:
poulsbo:/home # l ./jsa/.cache/google-chrome/Default/old_Cache_000/f_0259ff ls: cannot access ./jsa/.cache/google-chrome/Default/old_Cache_000/f_0259ff: Structure needs cleaning
If I list the entire directory I get this:
poulsbo:/home # l ./jsa/.cache/google-chrome/Default/old_Cache_000/ ls: cannot access ./jsa/.cache/google-chrome/Default/old_Cache_000/f_0259ff: Structure needs cleaning total 70772 drwx------ 2 jsa users 94208 May 31 12:38 ./ drwx------ 5 jsa users 59 Jun 2 14:37 ../ -rw------- 1 jsa users 10231808 May 31 12:31 data_4 ...snip -rw------- 1 jsa users 32938 Feb 14 2016 f_020630 -????????? ? ? ? ? ? f_0259ff -rw------- 1 jsa users 33622 Mar 17 2016 f_025fef
Over on the XFS site Faq them mumble something about question marks in the directory listing suggest you might need inode64, but its only a 500gig drive and this seems unwise at this poing. These also dumped the following into my log:
Oct 27 17:37:20 poulsbo.homeip.net kernel: XFS (dm-1): xfs_iread: validation failed for inode 537556822 failed Oct 27 17:37:20 poulsbo.homeip.net kernel: ffff8800a928fc00: 49 4e 81 80 03 02 00 00 00 00 03 e8 00 00 00 64 IN.............d Oct 27 17:37:20 poulsbo.homeip.net kernel: ffff8800a928fc10: 00 00 00 01 00 00 00 00 00 00 00 00 00 00 00 00 ................ Oct 27 17:37:20 poulsbo.homeip.net kernel: ffff8800a928fc20: 56 e9 94 78 12 00 ec 9f 56 e9 94 78 12 10 2e c5 V..x....V..x.... Oct 27 17:37:20 poulsbo.homeip.net kernel: ffff8800a928fc30: 56 e9 94 78 12 10 2e c5 00 00 00 00 00 02 72 5d V..x..........r] Oct 27 17:37:20 poulsbo.homeip.net kernel: XFS (dm-1): Internal error xfs_iread at line 392 of file ../fs/xfs/xfs_inode_buf.c. Caller xfs_iget+0x298/0x7f0 [xfs] Oct 27 17:37:21 poulsbo.homeip.net kernel: CPU: 1 PID: 16839 Comm: ls Not tainted 3.16.7-45-desktop #1 Oct 27 17:37:21 poulsbo.homeip.net kernel: Hardware name: Dell Inc. MP061 /0YD479, BIOS A08 04/02/2007 Oct 27 17:37:21 poulsbo.homeip.net kernel: 0000000000000001 ffffffff8161e1f6 ffff8800a203f000 ffffffffa07e506b Oct 27 17:37:21 poulsbo.homeip.net kernel: 00000188ba9be7c0 ffffffffa07eadb8 ffff88001f091400 ffff8800a203f000 Oct 27 17:37:21 poulsbo.homeip.net kernel: 0000000000000075 0000000000000000 ffffffffa0832eba ffffffffa07eadb8 Oct 27 17:37:21 poulsbo.homeip.net kernel: Call Trace: Oct 27 17:37:21 poulsbo.homeip.net kernel: [<ffffffff810051ee>] dump_trace+0x8e/0x350 Oct 27 17:37:21 poulsbo.homeip.net kernel: [<ffffffff81005556>] show_stack_log_lvl+0xa6/0x190 Oct 27 17:37:21 poulsbo.homeip.net kernel: [<ffffffff81006aa1>] show_stack+0x21/0x50 Oct 27 17:37:21 poulsbo.homeip.net kernel: [<ffffffff8161e1f6>] dump_stack+0x49/0x6a Oct 27 17:37:21 poulsbo.homeip.net kernel: [<ffffffffa07e506b>] xfs_corruption_error+0x5b/0x80 [xfs] Oct 27 17:37:21 poulsbo.homeip.net kernel: [<ffffffffa0832eba>] xfs_iread+0xea/0x400 [xfs] Oct 27 17:37:21 poulsbo.homeip.net kernel: [<ffffffffa07eadb8>] xfs_iget+0x298/0x7f0 [xfs] Oct 27 17:37:21 poulsbo.homeip.net kernel: [<ffffffffa082cf2e>] xfs_lookup+0xee/0x110 [xfs] Oct 27 17:37:21 poulsbo.homeip.net kernel: [<ffffffffa07f0306>] xfs_vn_lookup+0x56/0xa0 [xfs] Oct 27 17:37:21 poulsbo.homeip.net kernel: [<ffffffff811c1a59>] lookup_real+0x19/0x50 Oct 27 17:37:21 poulsbo.homeip.net kernel: [<ffffffff811c234f>] __lookup_hash+0x2f/0x40 Oct 27 17:37:21 poulsbo.homeip.net kernel: [<ffffffff8161b550>] lookup_slow+0x3e/0xa3 Oct 27 17:37:21 poulsbo.homeip.net kernel: [<ffffffff811c52a5>] path_lookupat+0x725/0x790 Oct 27 17:37:21 poulsbo.homeip.net kernel: [<ffffffff811c5336>] filename_lookup+0x26/0xc0 Oct 27 17:37:21 poulsbo.homeip.net kernel: [<ffffffff811c8b54>] user_path_at_empty+0x54/0x90 Oct 27 17:37:21 poulsbo.homeip.net kernel: [<ffffffff811bd2d6>] vfs_fstatat+0x46/0x90 Oct 27 17:37:21 poulsbo.homeip.net kernel: [<ffffffff811bd7ad>] SYSC_newlstat+0x1d/0x40 Oct 27 17:37:21 poulsbo.homeip.net kernel: [<ffffffff81624f0d>] system_call_fastpath+0x1a/0x1f Oct 27 17:37:21 poulsbo.homeip.net kernel: [<00007fecc5b6dd35>] 0x7fecc5b6dd34 Oct 27 17:37:21 poulsbo.homeip.net kernel: XFS (dm-1): Corruption detected. Unmount and run xfs_repair
So I did as directed, unmounted it and ran xfs_repair on the /dev/mapper/cr_yaddayadda device that represents the encrypted partition /dev/sda4. (it is said to be pointless and dangerous to run xfs_repair on the actual underlying device. Is this true? Its still xfs underneath is it not? ). After multiple such runs, no error is found by xfs_repair, and the problem is not repaired. smartctl shows no errors and no sectors having been re-mapped. The drive appears physically fine. So how do I proceed from here? I have two such little files that barf in the log each time I even try to peek at them. -- After all is said and done, more is said than done. -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
Hello John, save your time. XFS is crap - go back to ext4, this is working flawlessly. I have been facing the very same issues on two notebooks. No fix, no repair, the tools are as stubborn as can be - I do not know who came to the conclusion XFS would be a good choice for a stable system ... This does not really help - but the best to do is get rid of it. Take care Dieter Jurzitza Am Donnerstag, 27. Oktober 2016, 18:03:24 schrieb John Andersen:
I have a /home partition using luks on xfs
I've got two little files that barfed up errors while running a backup. **************+
-- ----------------------------------------------------------- Dr.-Ing. Dieter Jurzitza 76131 Karlsruhe -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
On Fri, 28 Oct 2016 19:17:34 +0200 "Dr.-Ing. Dieter Jurzitza" <dieter.jurzitza@t-online.de> wrote:
Hello John, save your time. XFS is crap - go back to ext4, this is working flawlessly. I have been facing the very same issues on two notebooks. No fix, no repair, the tools are as stubborn as can be - I do not know who came to the conclusion XFS would be a good choice for a stable system ... This does not really help - but the best to do is get rid of it. Take care
My opinion is very different. I've used XFS for many years with no problems and found the XFS folks very helpful. I've also used Reiser for years with no problems. I trust all my data to one or the other. Cheers, Dave
Dieter Jurzitza
Am Donnerstag, 27. Oktober 2016, 18:03:24 schrieb John Andersen:
I have a /home partition using luks on xfs
I've got two little files that barfed up errors while running a backup. **************+
-- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
On 2016-10-29 00:35, Dave Howorth wrote:
On Fri, 28 Oct 2016 19:17:34 +0200 "Dr.-Ing. Dieter Jurzitza" <dieter.jurzitza@t-online.de> wrote:
Hello John, save your time. XFS is crap - go back to ext4, this is working flawlessly. I have been facing the very same issues on two notebooks. No fix, no repair, the tools are as stubborn as can be - I do not know who came to the conclusion XFS would be a good choice for a stable system ... This does not really help - but the best to do is get rid of it. Take care
My opinion is very different. I've used XFS for many years with no problems and found the XFS folks very helpful. I've also used Reiser for years with no problems. I trust all my data to one or the other.
Same here. XFS is very good, and its developers are quite active at solving problems like this in the XFS mailing list. -- Cheers / Saludos, Carlos E. R. (from 13.1 x86_64 "Bottle" at Telcontar)
On Thu, 27 Oct 2016 18:03:24 -0700 John Andersen <jsamyth@gmail.com> wrote:
I have a /home partition using luks on xfs
I've got two little files that barfed up errors while running a backup. Any attempt to access these files results in an error:
poulsbo:/home # l ./jsa/.cache/google-chrome/Default/old_Cache_000/f_0259ff ls: cannot access ./jsa/.cache/google-chrome/Default/old_Cache_000/f_0259ff: Structure needs cleaning
If I list the entire directory I get this:
poulsbo:/home # l ./jsa/.cache/google-chrome/Default/old_Cache_000/ ls: cannot access ./jsa/.cache/google-chrome/Default/old_Cache_000/f_0259ff: Structure needs cleaning total 70772 drwx------ 2 jsa users 94208 May 31 12:38 ./ drwx------ 5 jsa users 59 Jun 2 14:37 ../ -rw------- 1 jsa users 10231808 May 31 12:31 data_4 ...snip -rw------- 1 jsa users 32938 Feb 14 2016 f_020630 -????????? ? ? ? ? ? f_0259ff -rw------- 1 jsa users 33622 Mar 17 2016 f_025fef
Over on the XFS site Faq them mumble something about question marks in the directory listing suggest you might need inode64, but its only a 500gig drive and this seems unwise at this poing.
These also dumped the following into my log:
Oct 27 17:37:20 poulsbo.homeip.net kernel: XFS (dm-1): xfs_iread: validation failed for inode 537556822 failed Oct 27 17:37:20 poulsbo.homeip.net kernel: ffff8800a928fc00: 49 4e 81 80 03 02 00 00 00 00 03 e8 00 00 00 64 IN.............d Oct 27 17:37:20 poulsbo.homeip.net kernel: ffff8800a928fc10: 00 00 00 01 00 00 00 00 00 00 00 00 00 00 00 00 ................ Oct 27 17:37:20 poulsbo.homeip.net kernel: ffff8800a928fc20: 56 e9 94 78 12 00 ec 9f 56 e9 94 78 12 10 2e c5 V..x....V..x.... Oct 27 17:37:20 poulsbo.homeip.net kernel: ffff8800a928fc30: 56 e9 94 78 12 10 2e c5 00 00 00 00 00 02 72 5d V..x..........r] Oct 27 17:37:20 poulsbo.homeip.net kernel: XFS (dm-1): Internal error xfs_iread at line 392 of file ../fs/xfs/xfs_inode_buf.c. Caller xfs_iget+0x298/0x7f0 [xfs] Oct 27 17:37:21 poulsbo.homeip.net kernel: CPU: 1 PID: 16839 Comm: ls Not tainted 3.16.7-45-desktop #1 Oct 27 17:37:21 poulsbo.homeip.net kernel: Hardware name: Dell Inc. MP061 /0YD479, BIOS A08 04/02/2007 Oct 27 17:37:21 poulsbo.homeip.net kernel: 0000000000000001 ffffffff8161e1f6 ffff8800a203f000 ffffffffa07e506b Oct 27 17:37:21 poulsbo.homeip.net kernel: 00000188ba9be7c0 ffffffffa07eadb8 ffff88001f091400 ffff8800a203f000 Oct 27 17:37:21 poulsbo.homeip.net kernel: 0000000000000075 0000000000000000 ffffffffa0832eba ffffffffa07eadb8 Oct 27 17:37:21 poulsbo.homeip.net kernel: Call Trace: Oct 27 17:37:21 poulsbo.homeip.net kernel: [<ffffffff810051ee>] dump_trace+0x8e/0x350 Oct 27 17:37:21 poulsbo.homeip.net kernel: [<ffffffff81005556>] show_stack_log_lvl+0xa6/0x190 Oct 27 17:37:21 poulsbo.homeip.net kernel: [<ffffffff81006aa1>] show_stack+0x21/0x50 Oct 27 17:37:21 poulsbo.homeip.net kernel: [<ffffffff8161e1f6>] dump_stack+0x49/0x6a Oct 27 17:37:21 poulsbo.homeip.net kernel: [<ffffffffa07e506b>] xfs_corruption_error+0x5b/0x80 [xfs] Oct 27 17:37:21 poulsbo.homeip.net kernel: [<ffffffffa0832eba>] xfs_iread+0xea/0x400 [xfs] Oct 27 17:37:21 poulsbo.homeip.net kernel: [<ffffffffa07eadb8>] xfs_iget+0x298/0x7f0 [xfs] Oct 27 17:37:21 poulsbo.homeip.net kernel: [<ffffffffa082cf2e>] xfs_lookup+0xee/0x110 [xfs] Oct 27 17:37:21 poulsbo.homeip.net kernel: [<ffffffffa07f0306>] xfs_vn_lookup+0x56/0xa0 [xfs] Oct 27 17:37:21 poulsbo.homeip.net kernel: [<ffffffff811c1a59>] lookup_real+0x19/0x50 Oct 27 17:37:21 poulsbo.homeip.net kernel: [<ffffffff811c234f>] __lookup_hash+0x2f/0x40 Oct 27 17:37:21 poulsbo.homeip.net kernel: [<ffffffff8161b550>] lookup_slow+0x3e/0xa3 Oct 27 17:37:21 poulsbo.homeip.net kernel: [<ffffffff811c52a5>] path_lookupat+0x725/0x790 Oct 27 17:37:21 poulsbo.homeip.net kernel: [<ffffffff811c5336>] filename_lookup+0x26/0xc0 Oct 27 17:37:21 poulsbo.homeip.net kernel: [<ffffffff811c8b54>] user_path_at_empty+0x54/0x90 Oct 27 17:37:21 poulsbo.homeip.net kernel: [<ffffffff811bd2d6>] vfs_fstatat+0x46/0x90 Oct 27 17:37:21 poulsbo.homeip.net kernel: [<ffffffff811bd7ad>] SYSC_newlstat+0x1d/0x40 Oct 27 17:37:21 poulsbo.homeip.net kernel: [<ffffffff81624f0d>] system_call_fastpath+0x1a/0x1f Oct 27 17:37:21 poulsbo.homeip.net kernel: [<00007fecc5b6dd35>] 0x7fecc5b6dd34 Oct 27 17:37:21 poulsbo.homeip.net kernel: XFS (dm-1): Corruption detected. Unmount and run xfs_repair
So I did as directed, unmounted it and ran xfs_repair on the /dev/mapper/cr_yaddayadda device that represents the encrypted partition /dev/sda4.
(it is said to be pointless and dangerous to run xfs_repair on the actual underlying device. Is this true? Its still xfs underneath is it not? ).
XFS underneath the crypto? That sounds pretty ridiculous does it not?
After multiple such runs, no error is found by xfs_repair, and the problem is not repaired.
smartctl shows no errors and no sectors having been re-mapped. The drive appears physically fine.
So how do I proceed from here? I have two such little files that barf in the log each time I even try to peek at them.
Either ignore those two files and replace them from your backup, or take the symptoms to the XFS mailing list would be my suggestion. I seem to remember they have a document on what evidence to supply when reporting a problem, and they react well if you do that. -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
On 10/28/2016 02:39 PM, Dave Howorth wrote:
On Thu, 27 Oct 2016 18:03:24 -0700 John Andersen <jsamyth@gmail.com> wrote:
So I did as directed, unmounted it and ran xfs_repair on the /dev/mapper/cr_yaddayadda device that represents the encrypted partition /dev/sda4.
(it is said to be pointless and dangerous to run xfs_repair on the actual underlying device. Is this true? Its still xfs underneath is it not? ).
Yet this was actually recommended by one source. Of course I declined to do that. An inode may still be an inode under the crypto, with only the content encrypted, but I had no intention of finding that out the hard way.
XFS underneath the crypto? That sounds pretty ridiculous does it not?
After multiple such runs, no error is found by xfs_repair, and the problem is not repaired.
smartctl shows no errors and no sectors having been re-mapped. The drive appears physically fine.
So how do I proceed from here? I have two such little files that barf in the log each time I even try to peek at them.
Either ignore those two files and replace them from your backup, or take the symptoms to the XFS mailing list would be my suggestion. I seem to remember they have a document on what evidence to supply when reporting a problem, and they react well if you do that.
These two errors occured in a chromium cache directory, and a kopete config directory for a now defunct jabber account, so they are easily abandoned and the surrounding directory trimmed to the minimum. No need to restore but also no possibility to remove them. I have no other option but to abandon them nor nuke the partition at this point. -- After all is said and done, more is said than done. -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
John Andersen wrote:
If I list the entire directory I get this:
poulsbo:/home # l ./jsa/.cache/google-chrome/Default/old_Cache_000/ ls: cannot access ./jsa/.cache/google-chrome/Default/old_Cache_000/f_0259ff: Structure needs cleaning total 70772 drwx------ 2 jsa users 94208 May 31 12:38 ./ drwx------ 5 jsa users 59 Jun 2 14:37 ../ -rw------- 1 jsa users 10231808 May 31 12:31 data_4 ...snip -rw------- 1 jsa users 32938 Feb 14 2016 f_020630 -????????? ? ? ? ? ? f_0259ff -rw------- 1 jsa users 33622 Mar 17 2016 f_025fef
Over on the XFS site Faq them mumble something about question marks in the directory listing suggest you might need inode64, but its only a 500gig drive and this seems unwise at this poing.
you are missing their point. It **looks** like that partition was already used with the "inode64" option. Once you use that option, you can't go back because files are created in the new format. If you later mount the disk without that option, you see output similar to what you are showing above. It's not that you need to move to inode64, its that you need to try it because it looks like the partition already has been used with that option.
These also dumped the following into my log:
---- If you have the wrong mount options, and are telling it to ignore the new inodes, there will be much confusion and possibly kernel panics.
So I did as directed, unmounted it and ran xfs_repair on the /dev/mapper/cr_yaddayadda device that represents the encrypted partition /dev/sda4.
AND it is encrypted?
(it is said to be pointless and dangerous to run xfs_repair on the actual underlying device. Is this true? Its still xfs underneath is it not? ).
---- No. Under the encryption layer, it is garbage. If you ran repair on the underlying partion first, it likely trashed the partition.
After multiple such runs, no error is found by xfs_repair, and the problem is not repaired.
If the disk is corrupt due to bad mount options and/or trying to repair a raw-encrypted partition, it's likely unrepairable. I'd restore from a backup.
smartctl shows no errors and no sectors having been re-mapped. The drive appears physically fine.
So how do I proceed from here?
--- restore from backup. -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
What Linda wrote seemed quite likely. See below... On Fri, 28 Oct 2016 23:20:50 -0700 Linda Walsh <suse@tlinx.org> wrote:
John Andersen wrote:
If I list the entire directory I get this:
poulsbo:/home # l ./jsa/.cache/google-chrome/Default/old_Cache_000/ ls: cannot access ./jsa/.cache/google-chrome/Default/old_Cache_000/f_0259ff: Structure needs cleaning total 70772 drwx------ 2 jsa users 94208 May 31 12:38 ./ drwx------ 5 jsa users 59 Jun 2 14:37 ../ -rw------- 1 jsa users 10231808 May 31 12:31 data_4 ...snip -rw------- 1 jsa users 32938 Feb 14 2016 f_020630 -????????? ? ? ? ? ? f_0259ff -rw------- 1 jsa users 33622 Mar 17 2016 f_025fef
Over on the XFS site Faq them mumble something about question marks in the directory listing suggest you might need inode64, but its only a 500gig drive and this seems unwise at this poing.
you are missing their point. It **looks** like that partition was already used with the "inode64" option. Once you use that option, you can't go back because files are created in the new format. If you later mount the disk without that option, you see output similar to what you are showing above.
It's not that you need to move to inode64, its that you need to try it because it looks like the partition already has been used with that option.
I think it might be worth trying that option. If that doesn't work, then as Linda says, restore from backup.
These also dumped the following into my log:
---- If you have the wrong mount options, and are telling it to ignore the new inodes, there will be much confusion and possibly kernel panics.
So I did as directed, unmounted it and ran xfs_repair on the /dev/mapper/cr_yaddayadda device that represents the encrypted partition /dev/sda4.
AND it is encrypted?
(it is said to be pointless and dangerous to run xfs_repair on the actual underlying device. Is this true? Its still xfs underneath is it not? ).
---- No. Under the encryption layer, it is garbage. If you ran repair on the underlying partion first, it likely trashed the partition.
After multiple such runs, no error is found by xfs_repair, and the problem is not repaired.
If the disk is corrupt due to bad mount options and/or trying to repair a raw-encrypted partition, it's likely unrepairable.
I'd restore from a backup.
smartctl shows no errors and no sectors having been re-mapped. The drive appears physically fine.
So how do I proceed from here?
---
restore from backup.
-- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
On 10/29/2016 02:44 PM, Dave Howorth wrote:
What Linda wrote seemed quite likely. See below...
No, it seemed wrong on many accounts: 1) the system was never mounted with inode64. It was set up and rock solid since 6 months after 13.2 release date. 2) this was a known deficiency in xfs_repair 3.2.1 long since fixed but never for OS 13.2. 3) there were exactly two inodes that were trashed somehow, not hundreds. 3) Restore from a backup would not have fixed anything, as the two corrupted inodes would still be corrupted, could not be rewritten or removed, may not have been un-linkable, and those files were browser cache detritus anyway. These never caused errors until a filesystem backup tried to read them. 4) Last known access to these files was in June, (judging by dates surrounding them and their appearance in prior backups but not on subsequent backups). 5) There appears NOT to have been any issue relating to LUKS encryption here, other than needing to run the xfs_repair against the /dev/mapper partition, which is the only listing in fstab for this partition. (The underlying hardware partition (/dev/sda4) is not shown in fstab, and I was well aware of not wanting to address that anyway. I tried to reply to her post, but did so on my phone while riding transit and lost the entire thing.
On Fri, 28 Oct 2016 23:20:50 -0700 Linda Walsh <suse@tlinx.org> wrote:
John Andersen wrote:
If I list the entire directory I get this:
poulsbo:/home # l ./jsa/.cache/google-chrome/Default/old_Cache_000/ ls: cannot access ./jsa/.cache/google-chrome/Default/old_Cache_000/f_0259ff: Structure needs cleaning total 70772 drwx------ 2 jsa users 94208 May 31 12:38 ./ drwx------ 5 jsa users 59 Jun 2 14:37 ../ -rw------- 1 jsa users 10231808 May 31 12:31 data_4 ...snip -rw------- 1 jsa users 32938 Feb 14 2016 f_020630 -????????? ? ? ? ? ? f_0259ff -rw------- 1 jsa users 33622 Mar 17 2016 f_025fef
Over on the XFS site Faq them mumble something about question marks in the directory listing suggest you might need inode64, but its only a 500gig drive and this seems unwise at this poing.
you are missing their point. It **looks** like that partition was already used with the "inode64" option. Once you use that option, you can't go back because files are created in the new format. If you later mount the disk without that option, you see output similar to what you are showing above.
It's not that you need to move to inode64, its that you need to try it because it looks like the partition already has been used with that option.
I think it might be worth trying that option. If that doesn't work, then as Linda says, restore from backup.
These also dumped the following into my log:
---- If you have the wrong mount options, and are telling it to ignore the new inodes, there will be much confusion and possibly kernel panics.
So I did as directed, unmounted it and ran xfs_repair on the /dev/mapper/cr_yaddayadda device that represents the encrypted partition /dev/sda4.
AND it is encrypted?
(it is said to be pointless and dangerous to run xfs_repair on the actual underlying device. Is this true? Its still xfs underneath is it not? ).
---- No. Under the encryption layer, it is garbage. If you ran repair on the underlying partion first, it likely trashed the partition.
After multiple such runs, no error is found by xfs_repair, and the problem is not repaired.
If the disk is corrupt due to bad mount options and/or trying to repair a raw-encrypted partition, it's likely unrepairable.
I'd restore from a backup.
smartctl shows no errors and no sectors having been re-mapped. The drive appears physically fine.
So how do I proceed from here?
---
restore from backup.
-- After all is said and done, more is said than done. -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
On Sat, 29 Oct 2016 15:11:31 -0700 John Andersen <jsamyth@gmail.com> wrote:
On 10/29/2016 02:44 PM, Dave Howorth wrote:
What Linda wrote seemed quite likely. See below...
No, it seemed wrong on many accounts:
Ah, I obviously missed all the facts below that you must have posted in your first message, but since you already completely understand, I guess you don't need people trying to be helpful.
1) the system was never mounted with inode64. It was set up and rock solid since 6 months after 13.2 release date.
2) this was a known deficiency in xfs_repair 3.2.1 long since fixed but never for OS 13.2.
3) there were exactly two inodes that were trashed somehow, not hundreds.
3) Restore from a backup would not have fixed anything, as the two corrupted inodes would still be corrupted, could not be rewritten or removed, may not have been un-linkable, and those files were browser cache detritus anyway. These never caused errors until a filesystem backup tried to read them.
4) Last known access to these files was in June, (judging by dates surrounding them and their appearance in prior backups but not on subsequent backups).
5) There appears NOT to have been any issue relating to LUKS encryption here, other than needing to run the xfs_repair against the /dev/mapper partition, which is the only listing in fstab for this partition. (The underlying hardware partition (/dev/sda4) is not shown in fstab, and I was well aware of not wanting to address that anyway.
I tried to reply to her post, but did so on my phone while riding transit and lost the entire thing.
On Fri, 28 Oct 2016 23:20:50 -0700 Linda Walsh <suse@tlinx.org> wrote:
John Andersen wrote:
If I list the entire directory I get this:
poulsbo:/home # l ./jsa/.cache/google-chrome/Default/old_Cache_000/ ls: cannot access ./jsa/.cache/google-chrome/Default/old_Cache_000/f_0259ff: Structure needs cleaning total 70772 drwx------ 2 jsa users 94208 May 31 12:38 ./ drwx------ 5 jsa users 59 Jun 2 14:37 ../ -rw------- 1 jsa users 10231808 May 31 12:31 data_4 ...snip -rw------- 1 jsa users 32938 Feb 14 2016 f_020630 -????????? ? ? ? ? ? f_0259ff -rw------- 1 jsa users 33622 Mar 17 2016 f_025fef
Over on the XFS site Faq them mumble something about question marks in the directory listing suggest you might need inode64, but its only a 500gig drive and this seems unwise at this poing.
you are missing their point. It **looks** like that partition was already used with the "inode64" option. Once you use that option, you can't go back because files are created in the new format. If you later mount the disk without that option, you see output similar to what you are showing above.
It's not that you need to move to inode64, its that you need to try it because it looks like the partition already has been used with that option.
I think it might be worth trying that option. If that doesn't work, then as Linda says, restore from backup.
These also dumped the following into my log:
---- If you have the wrong mount options, and are telling it to ignore the new inodes, there will be much confusion and possibly kernel panics.
So I did as directed, unmounted it and ran xfs_repair on the /dev/mapper/cr_yaddayadda device that represents the encrypted partition /dev/sda4.
AND it is encrypted?
(it is said to be pointless and dangerous to run xfs_repair on the actual underlying device. Is this true? Its still xfs underneath is it not? ).
---- No. Under the encryption layer, it is garbage. If you ran repair on the underlying partion first, it likely trashed the partition.
After multiple such runs, no error is found by xfs_repair, and the problem is not repaired.
If the disk is corrupt due to bad mount options and/or trying to repair a raw-encrypted partition, it's likely unrepairable.
I'd restore from a backup.
smartctl shows no errors and no sectors having been re-mapped. The drive appears physically fine.
So how do I proceed from here?
---
restore from backup.
-- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On Thursday, 2016-10-27 at 18:03 -0700, John Andersen wrote:
I have a /home partition using luks on xfs
What openSUSE version are you using?
I've got two little files that barfed up errors while running a backup. Any attempt to access these files results in an error:
...
These also dumped the following into my log:
Oct 27 17:37:20 poulsbo.homeip.net kernel: XFS (dm-1): xfs_iread: validation failed for inode 537556822 failed Oct 27 17:37:20 poulsbo.homeip.net kernel: ffff8800a928fc00: 49 4e 81 80 03 02 00 00 00 00 03 e8 00 00 00 64 IN.............d ... Oct 27 17:37:21 poulsbo.homeip.net kernel: XFS (dm-1): Corruption detected. Unmount and run xfs_repair
So I did as directed, unmounted it and ran xfs_repair on the /dev/mapper/cr_yaddayadda device that represents the encrypted partition /dev/sda4.
Yes, correct. There is probably a new toolset in the filesystem repo, but I don't know what versiohn you are running.
(it is said to be pointless and dangerous to run xfs_repair on the actual underlying device. Is this true? Its still xfs underneath is it not? ).
Absolutely true. If you look at it appears as noise, not a filesystem.
After multiple such runs, no error is found by xfs_repair, and the problem is not repaired.
smartctl shows no errors and no sectors having been re-mapped. The drive appears physically fine.
So how do I proceed from here? I have two such little files that barf in the log each time I even try to peek at them.
Post for help at the XFS mailing list: X-Mailing-List: linux-xfs at vger.kernel.org vger.kernel.org/vger-lists.html#linux-xfs But first, try a newer version of the repair tools. - -- Cheers, Carlos E. R. (from 13.1 x86_64 "Bottle" at Telcontar) -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.22 (GNU/Linux) iEYEARECAAYFAlgUovQACgkQtTMYHG2NR9UvpACfdt0/z3rDlJGiNFVvzTaXaiLp nNcAn3fQycCdRsYgO4m/SqQOjBYsoPT8 =Nv4q -----END PGP SIGNATURE----- -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
On 10/29/2016 06:24 AM, Carlos E. R. wrote:
On Thursday, 2016-10-27 at 18:03 -0700, John Andersen wrote:
I have a /home partition using luks on xfs
What openSUSE version are you using?
Opensuse 13.2 installed and set up as new partitions about the time changed over from btrfs. Its my /Home partition/
So I did as directed, unmounted it and ran xfs_repair on the /dev/mapper/cr_yaddayadda device that represents the encrypted partition /dev/sda4.
Yes, correct.
There is probably a new toolset in the filesystem repo, but I don't know what versiohn you are running.
xfs_repair version 3.2.1 (the latest I can find for 13.2 on opensuse 13.2 repositories.
So how do I proceed from here? I have two such little files that barf in the log each time I even try to peek at them.
Post for help at the XFS mailing list:
X-Mailing-List: linux-xfs at vger.kernel.org
vger.kernel.org/vger-lists.html#linux-xfs
But first, try a newer version of the repair tools.
And where would I get such? -- After all is said and done, more is said than done.
On 2016-10-29 20:06, John Andersen wrote:
On 10/29/2016 06:24 AM, Carlos E. R. wrote:
Opensuse 13.2 installed and set up as new partitions about the time changed over from btrfs. Its my /Home partition/
So I did as directed, unmounted it and ran xfs_repair on the /dev/mapper/cr_yaddayadda device that represents the encrypted partition /dev/sda4.
Yes, correct.
There is probably a new toolset in the filesystem repo, but I don't know what versiohn you are running.
xfs_repair version 3.2.1 (the latest I can find for 13.2 on opensuse 13.2 repositories.
I see 4.5 for 13.2. https://software.opensuse.org/package/xfsprogs?search_term=xfsprogs -- Cheers / Saludos, Carlos E. R. (from 13.1 x86_64 "Bottle" at Telcontar)
On 10/29/2016 11:17 AM, Carlos E. R. wrote:
On 2016-10-29 20:06, John Andersen wrote:
On 10/29/2016 06:24 AM, Carlos E. R. wrote:
Opensuse 13.2 installed and set up as new partitions about the time changed over from btrfs. Its my /Home partition/
So I did as directed, unmounted it and ran xfs_repair on the /dev/mapper/cr_yaddayadda device that represents the encrypted partition /dev/sda4.
Yes, correct.
There is probably a new toolset in the filesystem repo, but I don't know what versiohn you are running.
xfs_repair version 3.2.1 (the latest I can find for 13.2 on opensuse 13.2 repositories.
I see 4.5 for 13.2.
https://software.opensuse.org/package/xfsprogs?search_term=xfsprogs
That appears to be the same version I have, 3.2.1. Why did you think that was 4.5? -- After all is said and done, more is said than done.
On 2016-10-29 20:28, John Andersen wrote:
On 10/29/2016 11:17 AM, Carlos E. R. wrote:
xfs_repair version 3.2.1 (the latest I can find for 13.2 on opensuse 13.2 repositories.
I see 4.5 for 13.2.
https://software.opensuse.org/package/xfsprogs?search_term=xfsprogs
That appears to be the same version I have, 3.2.1. Why did you think that was 4.5?
Then look again. There is 4.5, in the filesystems repo. Hint: remember to click on "Show unstable packages". -- Cheers / Saludos, Carlos E. R. (from 13.1 x86_64 "Bottle" at Telcontar)
On 10/29/2016 01:39 PM, Carlos E. R. wrote:
Then look again. There is 4.5, in the filesystems repo.
Hint: remember to click on "Show unstable packages".
Ah, right you are. I see there are several sources. Question: Will I live to regret this? -- After all is said and done, more is said than done.
On 10/29/2016 04:43 PM, John Andersen wrote:
On 10/29/2016 01:39 PM, Carlos E. R. wrote:
Then look again. There is 4.5, in the filesystems repo.
Hint: remember to click on "Show unstable packages".
Ah, right you are.
I see there are several sources. Question: Will I live to regret this?
I doubt it. A while back I had a inoperable XFS and was pointed to that same package/repository. I installed the 4.5.0 and ran the repair and all was fin and has been ever since. You can see mention of this in the archives :-) -- A: Yes. > Q: Are you sure? >> A: Because it reverses the logical flow of conversation. >>> Q: Why is top posting frowned upon? -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
On 2016-10-29 22:43, John Andersen wrote:
On 10/29/2016 01:39 PM, Carlos E. R. wrote:
Then look again. There is 4.5, in the filesystems repo.
Hint: remember to click on "Show unstable packages".
Ah, right you are.
I see there are several sources.
One "filesystems" repo. I told you this hours ago...
Question: Will I live to regret this?
The wording "Show unstable packages" is incorrect, IMO. It should be "Show unofficial packages". Basically, you should avoid home repos unless told otherwise by its owner. The rest, depends. In this case, you absolutely need to update the xfsprogs package. Just remember not to use "zypper dup". -- Cheers / Saludos, Carlos E. R. (from 13.1 x86_64 "Bottle" at Telcontar)
On 10/29/2016 01:54 PM, Carlos E. R. wrote:
The wording "Show unstable packages" is incorrect, IMO. It should be "Show unofficial packages".
I totally missed the show unstable packages, and probably would have not used it had you not told me to do so. (The filesystem group didn't even show up unless that was selected.). In any event, I used one-click, installed 4.5.0, demounted the partition ran the new xfx_repair against the /dev/mapper/cr_ata-yada-yada and it found exactly two inodes and it rewrote those. The drive now shows clean again. Now why doesn't Opensuse push that version of xfsprogs to 13.2 rather than leaving everyone with a known broken version that has been a ticking timebomb for at least three of us on this list? -- After all is said and done, more is said than done.
On 2016-10-29 23:17, John Andersen wrote:
On 10/29/2016 01:54 PM, Carlos E. R. wrote:
The wording "Show unstable packages" is incorrect, IMO. It should be "Show unofficial packages".
I totally missed the show unstable packages, and probably would have not used it had you not told me to do so. (The filesystem group didn't even show up unless that was selected.).
In any event, I used one-click, installed 4.5.0, demounted the partition ran the new xfx_repair against the /dev/mapper/cr_ata-yada-yada and it found exactly two inodes and it rewrote those.
Ajá! Bingo!
The drive now shows clean again.
Now why doesn't Opensuse push that version of xfsprogs to 13.2 rather than leaving everyone with a known broken version that has been a ticking timebomb for at least three of us on this list?
Well... upgrades in general can be problematic. May not work well with something else that is on the system. Has not been tested with everything else. The openSUSE policy since ever has been to never upgrade packages to newer versions during the life of a release. But you have those updates if you want to try them, at your risk... Many people upgrade KDE or Gnome desktops. I don't, as a rule which sometimes I break. -- Cheers / Saludos, Carlos E. R. (from 13.1 x86_64 "Bottle" at Telcontar)
On 10/29/2016 05:18 PM, John Andersen wrote:
On 10/29/2016 01:54 PM, Carlos E. R. wrote:
Just remember not to use "zypper dup".
Noted.
And thanks for your help on this issue. You too Anton.
My apologies for not intervening earlier. Your use of encryption threw me. -- A: Yes. > Q: Are you sure? >> A: Because it reverses the logical flow of conversation. >>> Q: Why is top posting frowned upon? -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
On 10/29/2016 03:12 PM, Anton Aylward wrote:
On 10/29/2016 05:18 PM, John Andersen wrote:
On 10/29/2016 01:54 PM, Carlos E. R. wrote:
Just remember not to use "zypper dup".
Noted.
And thanks for your help on this issue. You too Anton.
My apologies for not intervening earlier. Your use of encryption threw me.
Turns out it (encryption) appears to be blameless here. I have two encrypted partitions on this machine (/home and /data ) because I have to carry customer data for development work, and they have strict requirements. The rest of the machine is EXT4, as data loss (twice) made me a permanent exile from BTRFS land. -- After all is said and done, more is said than done. -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
On 2016-10-30 00:22, John Andersen wrote:
On 10/29/2016 03:12 PM, Anton Aylward wrote:
Turns out it (encryption) appears to be blameless here.
Just a guess (I also have encrypted partitions with XFS on top). I think that the system does encription based on cluster or sector whatever. The smallest assignation unit that the filesystem may use. Anything larger would have to consider where a file starts and ends... so no, base it on sectors. Doing that way, you can not have whole partition corruption, or large corruption. Just so many sectors would become corrupt, and thus the filesystem on top corrupted. Correct the filesystem on top and the encryption layer is also corrected transparently... -- Cheers / Saludos, Carlos E. R. (from 13.1 x86_64 "Bottle" at Telcontar)
On 10/29/2016 11:17 AM, Carlos E. R. wrote:
xfs_repair version 3.2.1 (the latest I can find for 13.2 on opensuse 13.2 repositories. I see 4.5 for 13.2.
https://software.opensuse.org/package/xfsprogs?search_term=xfsprogs
No, that still appears to be 3.2.1 for Opensuse 13.2 Carlos. -- After all is said and done, more is said than done.
On 10/29/2016 06:24 AM, Carlos E. R. wrote:
Post for help at the XFS mailing list:
X-Mailing-List: linux-xfs at vger.kernel.org
vger.kernel.org/vger-lists.html#linux-xfs
That list does not seem the place for this type question. Its a high-level developers list, not an end-users list. I'd be as welcome there as sending the question to Linus himself. -- After all is said and done, more is said than done
On 2016-10-29 22:39, John Andersen wrote:
On 10/29/2016 06:24 AM, Carlos E. R. wrote:
Post for help at the XFS mailing list:
X-Mailing-List: linux-xfs at vger.kernel.org
vger.kernel.org/vger-lists.html#linux-xfs
That list does not seem the place for this type question. Its a high-level developers list, not an end-users list. I'd be as welcome there as sending the question to Linus himself.
Wrong :-) It is both a developer and a user list question. Yes, Linus himself writes there now and then. I write there, and I'm not a dev. They very much welcome users, when we have problems that they know they are the experts on. Just wait till you try with the updated xfs_repair tool, because chances are that the issue was already patched. If you check the archive you see questions like yours. Just that I don't remember the link to the information they require to analyze a problem. Basically logs and full output of the commands used since problem discovery. Earlier logs, sometimes, help. Once they asked me to send the metadata of one of my large filesystems, which is much smaller. I use google drive. They used that to analyze my disk and they discovered a bug. They are very nice people. -- Cheers / Saludos, Carlos E. R. (from 13.1 x86_64 "Bottle" at Telcontar)
On Sat, Oct 29, 2016 at 4:39 PM, John Andersen <jsamyth@gmail.com> wrote:
On 10/29/2016 06:24 AM, Carlos E. R. wrote:
Post for help at the XFS mailing list:
X-Mailing-List: linux-xfs at vger.kernel.org
vger.kernel.org/vger-lists.html#linux-xfs
That list does not seem the place for this type question. Its a high-level developers list, not an end-users list. I'd be as welcome there as sending the question to Linus himself.
John, I haven't followed this question, but I have followed the linux-xfs list. The developers there are amazingly willing to help end-users, as long as the end-users are willing (and able) to follow their advice and answer their questions. Greg -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
participants (7)
-
Anton Aylward -
Carlos E. R. -
Dave Howorth -
Dr.-Ing. Dieter Jurzitza -
Greg Freemyer -
John Andersen -
Linda Walsh