Files with non-ASCII names inaccessible after xfs_repair

Files with non-ASCII names inaccessible after xfs_repair

[Zachary Kotlarek]

[-- Attachment #1.1: Type: text/plain, Size: 1954 bytes --]

My XFS filesystem dismounted while copying a ~3 GB file. I won’t claim to know why; I’m fairly confident only that 1 file was being modified at the time. The log replayed cleanly when remounting, but attempting to remove the file in question caused the same dismount.

So I ran xfs_repair. It put one file in lost+found (which appears to be written when if failed initially) and reported a number or warnings to the effect of:
	bad hash table for directory inode 2054 (hash value mismatch): rebuilding
	rebuilding directory inode 2054 
which I didn’t take to be serious, though I suspect now that’s where things went wrong.

I now have 23 directories (matching the 23 “rebuilding" messages) where a file or directory with non-ASCII characters in the name exists in the directory list but cannot be read or deleted:

ls -la
ls: cannot access 07 - Señor Macho Solo.m4v: No such file or directory
-rw-rw----+  1 profplump media 332M Sep 11  2010 06 - Christmas Special.m4v
???????????  ? ?         ?        ?            ? 07 - Se??or Macho Solo.m4v
-rw-rw----+  1 profplump media 304M Sep 11  2010 08 - Flu Shot.m4v

So the file exists in the directory listing (`ls` and `find` can both see it) but I cannot delete or stat or open it. If I touch the affected filename I get a second entry in the directory listing, both apparently pointing to the same, new, empty file. If I then delete the same filename I get back to the original state — a single, unusable directory entry.

I’d like to (if possible) re-link those directory listings to the related files, or at least delete them so the files can be restored and folders can be used normally. I’m also worried that running xfs_repair in the future might re-create this problem.

But I don’t even know where to start in trying to fix this. And I still cannot delete the file that started this whole sequence of events. So if anyone has suggestions I’d be happy to hear them.

	Zach


[-- Attachment #1.2: smime.p7s --]
[-- Type: application/pkcs7-signature, Size: 2749 bytes --]

[-- Attachment #2: Type: text/plain, Size: 121 bytes --]

_______________________________________________
xfs mailing list
xfs@oss.sgi.com
http://oss.sgi.com/mailman/listinfo/xfs

Re: Files with non-ASCII names inaccessible after xfs_repair

[Stan Hoeppner]

On 1/12/2014 7:28 AM, Zachary Kotlarek wrote:
> My XFS filesystem dismounted while copying a ~3 GB file. I won’t
> claim to know why; I’m fairly confident only that 1 file was being
> modified at the time. The log replayed cleanly when remounting, but
> attempting to remove the file in question caused the same dismount.
> 
> So I ran xfs_repair. It put one file in lost+found (which appears to
> be written when if failed initially) and reported a number or
> warnings to the effect of: bad hash table for directory inode 2054
> (hash value mismatch): rebuilding rebuilding directory inode 2054 
> which I didn’t take to be serious, though I suspect now that’s where
> things went wrong.
> 
> I now have 23 directories (matching the 23 “rebuilding" messages)
> where a file or directory with non-ASCII characters in the name
> exists in the directory list but cannot be read or deleted:
> 
> ls -la ls: cannot access 07 - Señor Macho Solo.m4v: No such file or
> directory -rw-rw----+  1 profplump media 332M Sep 11  2010 06 -
> Christmas Special.m4v ???????????  ? ?         ?        ?
> ? 07 - Se??or Macho Solo.m4v -rw-rw----+  1 profplump media 304M Sep
> 11  2010 08 - Flu Shot.m4v
> 
> So the file exists in the directory listing (`ls` and `find` can both
> see it) but I cannot delete or stat or open it. If I touch the
> affected filename I get a second entry in the directory listing, both
> apparently pointing to the same, new, empty file. If I then delete
> the same filename I get back to the original state — a single,
> unusable directory entry.
> 
> I’d like to (if possible) re-link those directory listings to the
> related files, or at least delete them so the files can be restored
> and folders can be used normally. I’m also worried that running
> xfs_repair in the future might re-create this problem.
> 
> But I don’t even know where to start in trying to fix this. And I
> still cannot delete the file that started this whole sequence of
> events. So if anyone has suggestions I’d be happy to hear them.

Start here:

http://xfs.org/index.php/XFS_FAQ#Q:_What_information_should_I_include_when_reporting_a_problem.3F

If this is due to a bug it may have already been fixed.  Note the first
two things asked for.


-- 
Stan

_______________________________________________
xfs mailing list
xfs@oss.sgi.com
http://oss.sgi.com/mailman/listinfo/xfs

Re: Files with non-ASCII names inaccessible after xfs_repair

[Zachary Kotlarek]

[-- Attachment #1.1: Type: text/plain, Size: 2000 bytes --]


On Jan 12, 2014, at 10:47 AM, Stan Hoeppner <stan@hardwarefreak.com> wrote:

> http://xfs.org/index.php/XFS_FAQ#Q:_What_information_should_I_include_when_reporting_a_problem.3F
> 
> If this is due to a bug it may have already been fixed.  Note the first
> two things asked for.


Thanks for the pointer.

My kernels a bit old, but xfsprogs is shiny and new:
Linux vera 2.6.39.2 #1 SMP Fri Sep 30 23:55:41 PDT 2011 x86_64 x86_64 x86_64 GNU/Linux
xfs_repair version 3.1.11

2x4 core CPUs
8 GB RAM, mostly free (more than 6 GB cached)

Related mount:
/dev/lvmsas/tv /mnt/media/TV xfs rw,nosuid,nodev,noexec,relatime,attr2,delaylog,inode64,sunit=1024,swidth=4096,noquota 0 0

Underlying partition:
 254       31 16252928000 dm-31

Which is a no-frills LVM2 volume allocation over mdadm raid-6.

meta-data=/dev/lvmsas/tv         isize=256    agcount=33, agsize=126975872 blks
         =                       sectsz=512   attr=2
data     =                       bsize=4096   blocks=4063232000, imaxpct=5
         =                       sunit=128    swidth=512 blks
naming   =version 2              bsize=4096   ascii-ci=1
log      =internal               bsize=4096   blocks=521728, version=2
         =                       sectsz=512   sunit=8 blks, lazy-count=1
realtime =none                   extsz=4096   blocks=0, rtextents=0

Attempts to access the now-busted files/directories with accents in their paths result in a kernel log like:
Jan 11 02:05:39 vera XFS (dm-31): I/O error occurred: meta-data dev dm-31 block 0x3c8ff73e0       ("xfs_trans_read_buf") error 11 buf count 4096

Original failure never hit the persistent log so I don’t have that; the system would not shutdown cleanly and I kill it after several errors like:
	Filesystem "dm-31": xfs_log_force: error 5 returned.
It claimed to be unmounted at that point (it didn’t show up in /proc/mounts) but the related [xfsbufd/dm-31] process was still running and could not be killed.

	Zach


[-- Attachment #1.2: smime.p7s --]
[-- Type: application/pkcs7-signature, Size: 2749 bytes --]

[-- Attachment #2: Type: text/plain, Size: 121 bytes --]

_______________________________________________
xfs mailing list
xfs@oss.sgi.com
http://oss.sgi.com/mailman/listinfo/xfs

Re: Files with non-ASCII names inaccessible after xfs_repair

[Dave Chinner]

On Sun, Jan 12, 2014 at 11:53:59AM -0800, Zachary Kotlarek wrote:
> 
> On Jan 12, 2014, at 10:47 AM, Stan Hoeppner <stan@hardwarefreak.com> wrote:
> 
> > http://xfs.org/index.php/XFS_FAQ#Q:_What_information_should_I_include_when_reporting_a_problem.3F
> > 
> > If this is due to a bug it may have already been fixed.  Note the first
> > two things asked for.
> 
> 
> Thanks for the pointer.
> 
> My kernels a bit old, but xfsprogs is shiny and new:
> Linux vera 2.6.39.2 #1 SMP Fri Sep 30 23:55:41 PDT 2011 x86_64 x86_64 x86_64 GNU/Linux
> xfs_repair version 3.1.11
> 
> 2x4 core CPUs
> 8 GB RAM, mostly free (more than 6 GB cached)
> 
> Related mount:
> /dev/lvmsas/tv /mnt/media/TV xfs rw,nosuid,nodev,noexec,relatime,attr2,delaylog,inode64,sunit=1024,swidth=4096,noquota 0 0
> 
> Underlying partition:
>  254       31 16252928000 dm-31
> 
> Which is a no-frills LVM2 volume allocation over mdadm raid-6.
> 
> meta-data=/dev/lvmsas/tv         isize=256    agcount=33, agsize=126975872 blks
>          =                       sectsz=512   attr=2
> data     =                       bsize=4096   blocks=4063232000, imaxpct=5
>          =                       sunit=128    swidth=512 blks
> naming   =version 2              bsize=4096   ascii-ci=1
> log      =internal               bsize=4096   blocks=521728, version=2
>          =                       sectsz=512   sunit=8 blks, lazy-count=1
> realtime =none                   extsz=4096   blocks=0, rtextents=0
> 
> Attempts to access the now-busted files/directories with accents in their paths result in a kernel log like:
> Jan 11 02:05:39 vera XFS (dm-31): I/O error occurred: meta-data dev dm-31 block 0x3c8ff73e0       ("xfs_trans_read_buf") error 11 buf count 4096

error 11 = EAGAIN/EWOULDBLOCK

That tends to imply that there's some interesting error occurring in
the layers below XFS here. XFS on a kernel that old is not expecting
an EAGAIN error from storage, so it is likely not being captured
properly. There have been bugs in the raid/dm code in the past that
would cause issues like this, and bugs in the XFS error handling
that allowed them to slip throw and shut down the filesystem.

For example, this fix made in March 2013:

$ gl -n1 -p c163f9a
commit c163f9a1760229a95d04e37b332de7d5c1c225cd
Author: Dave Chinner <dchinner@redhat.com>
Date:   Tue Mar 12 23:30:34 2013 +1100

    xfs: ensure we capture IO errors correctly
    
    Failed buffer readahead can leave the buffer in the cache marked
    with an error. Most callers that then issue a subsequent read on the
    buffer do not zero the b_error field out, and so we may incorectly
    detect an error during IO completion due to the stale error value
    left on the buffer.
    
    Avoid this problem by zeroing the error before IO submission. This
    ensures that the only IO errors that are detected those captured
    from are those captured from bio submission or completion.
    
    Signed-off-by: Dave Chinner <dchinner@redhat.com>
    Reviewed-by: Mark Tinguely <tinguely@sgi.com>
    Signed-off-by: Ben Myers <bpm@sgi.com>

Is probably relevant, but there are many more changes up and down
the stack that may be the cause of your problem. Indeed, the above
fix may simply turn EAGAIN into EIO because there really is
something wrong with that block on disk....

Cheers,

Dave.
-- 
Dave Chinner
david@fromorbit.com

_______________________________________________
xfs mailing list
xfs@oss.sgi.com
http://oss.sgi.com/mailman/listinfo/xfs

Re: Files with non-ASCII names inaccessible after xfs_repair

[Zachary Kotlarek]

[-- Attachment #1.1: Type: text/plain, Size: 1282 bytes --]


On Jan 12, 2014, at 5:50 PM, Dave Chinner <david@fromorbit.com> wrote:

>> Attempts to access the now-busted files/directories with accents in their paths result in a kernel log like:
>> Jan 11 02:05:39 vera XFS (dm-31): I/O error occurred: meta-data dev dm-31 block 0x3c8ff73e0       ("xfs_trans_read_buf") error 11 buf count 4096
> 
> error 11 = EAGAIN/EWOULDBLOCK
> 
> That tends to imply that there's some interesting error occurring in
> the layers below XFS here.


The error you note only started showing up *after* the xfs_repair, and only when attempting to access the non-ascii file paths. It doesn’t take the filesystem offline; other than those particular paths being inaccessible the filesystem seems to be working correctly (though I’ve suspended user writes until this is worked out). The affected paths are all around the disk, all contain non-ascii characters in final portion of the path name, and do not affect other paths in the same directory.

I can find a newer kernel to boot off and see how it behaves if you think it would make any difference, but I’m pretty sure xfs_repair re-wrote the affected directory entries and broke them as opposed to some sort of block-layer corruption being responsible for breaking only these files.

	Zach


[-- Attachment #1.2: smime.p7s --]
[-- Type: application/pkcs7-signature, Size: 2749 bytes --]

[-- Attachment #2: Type: text/plain, Size: 121 bytes --]

_______________________________________________
xfs mailing list
xfs@oss.sgi.com
http://oss.sgi.com/mailman/listinfo/xfs

Re: Files with non-ASCII names inaccessible after xfs_repair

[Dave Chinner]

On Sun, Jan 12, 2014 at 06:36:03PM -0800, Zachary Kotlarek wrote:
> 
> On Jan 12, 2014, at 5:50 PM, Dave Chinner <david@fromorbit.com>
> wrote:
> 
> >> Attempts to access the now-busted files/directories with
> >> accents in their paths result in a kernel log like: Jan 11
> >> 02:05:39 vera XFS (dm-31): I/O error occurred: meta-data dev
> >> dm-31 block 0x3c8ff73e0       ("xfs_trans_read_buf") error 11
> >> buf count 4096
> > 
> > error 11 = EAGAIN/EWOULDBLOCK
> > 
> > That tends to imply that there's some interesting error
> > occurring in the layers below XFS here.
> 
> 
> The error you note only started showing up *after* the xfs_repair,
> and only when attempting to access the non-ascii file paths. It

Sure, but it's an error coming from the block layer, not from
decoding the contents of the block at the directory layer. IOWs,
xfs-repair wrote new contents to those blocks, and now the kernel
cannot read them from disk.

> doesn’t take the filesystem offline; other than those
> particular paths being inaccessible the filesystem seems to be
> working correctly (though I’ve suspended user writes until
> this is worked out).

Right - it's a read error, not a write error, so it simply returns
the error to the reader. However, if that read error occurs in the
context of a transaction that has already made modifications (e.g.
adding a new file to the directory) it will result in a shutdown of
the filesystem.

> The affected paths are all around the disk,
> all contain non-ascii characters in final portion of the path
> name, and do not affect other paths in the same directory.
> 
> I can find a newer kernel to boot off and see how it behaves if
> you think it would make any difference, but I’m pretty sure
> xfs_repair re-wrote the affected directory entries and broke them
> as opposed to some sort of block-layer corruption being
> responsible for breaking only these files.

Try using xfs_db to read and parse the blocks that the fielsystem is
choking on. If it can't read them from xfs_db, then there's
something gone wrong below XFS. If you can read them, use xfs_db to
parse the block as a directory block and see what the raw directory
entries are the block contains....

e.g.
# xfs_db <dev>
xfs_db> convert daddr 0x3c8ff73e0 fsb
<fsbno>
xfs_db> fsb <fsbno>
xfs_db> p
<hex output>
xfs_db> type dir2
xfs_db> p
<decoded output>

The decoded output should look something like:

xfs_db> p
dhdr.hdr.magic = 0x58444433
dhdr.hdr.crc = 0xc77dda8e (correct)
dhdr.hdr.bno = 1308
dhdr.hdr.lsn = 0xe60000aa35
dhdr.hdr.uuid = d2d0bec5-c8b8-420e-8a34-d981be7eece6
dhdr.hdr.owner = 32
dhdr.bestfree[0].offset = 0xa0
dhdr.bestfree[0].length = 0x10
dhdr.bestfree[1].offset = 0x4f8
dhdr.bestfree[1].length = 0x10
dhdr.bestfree[2].offset = 0x850
dhdr.bestfree[2].length = 0x10
du[0].inumber = 32
du[0].namelen = 1
du[0].name = "."
du[0].filetype = 2
du[0].tag = 0x40
du[1].inumber = 32
du[1].namelen = 2
du[1].name = ".."
du[1].filetype = 2
du[1].tag = 0x50
du[2].inumber = 393552
du[2].namelen = 3
du[2].name = "tmp"
du[2].filetype = 2
du[2].tag = 0x60
du[3].inumber = 36
du[3].namelen = 11
du[3].name = "syscalltest"
du[3].filetype = 1
du[3].tag = 0x70
du[4].inumber = 37
du[4].namelen = 8
du[4].name = "fsstress"
du[4].filetype = 2
du[4].tag = 0x88

if you do get the output like this, can you post both the hexdump
and the decoded output from xfs_db?

Hmmmm - you're not using LVM snapshots or anything like that are
you?

Cheers,

Dave.
-- 
Dave Chinner
david@fromorbit.com

_______________________________________________
xfs mailing list
xfs@oss.sgi.com
http://oss.sgi.com/mailman/listinfo/xfs

Re: Files with non-ASCII names inaccessible after xfs_repair

[Zachary Kotlarek]

[-- Attachment #1.1: Type: text/plain, Size: 18639 bytes --]


On Jan 12, 2014, at 7:19 PM, Dave Chinner <david@fromorbit.com> wrote:

> IOWs, xfs-repair wrote new contents to those blocks, and now the kernel
> cannot read them from disk.


Sure, but I don’t understand why it would have re-written them in the first place. I know corruption happens, but this seems awfully pattern-tastic to be random errors.


> Try using xfs_db to read and parse the blocks that the fielsystem is
> choking on. If it can't read them from xfs_db, then there's
> something gone wrong below XFS. If you can read them, use xfs_db to
> parse the block as a directory block and see what the raw directory
> entries are the block contains....
> 
> e.g.
> # xfs_db <dev>
> xfs_db> convert daddr 0x3c8ff73e0 fsb
> <fsbno>
> xfs_db> fsb <fsbno>
> xfs_db> p
> <hex output>
> xfs_db> type dir2
> xfs_db> p
> <decoded output>


Works.

xfs_db> convert daddr 0x3c8ff73e0 fsb
0x8007f67c (2148005500)
xfs_db> fsb 0x8007f67c
xfs_db> p
000: 58443242 075007d0 04600038 00b00030 00000008 007f681a 012ed556 11060010
020: 0000000c 80000800 022e2efe 68440020 ffff0020 007f6839 112e2e44 535f5374
040: 6f72652e 6b594c6b 4b32537a 78410030 00000008 007f6839 092e4453 5f53746f
060: 726597db 77f50050 ffff0028 007f683a 182e3031 202d2043 69747920 6f662e6d
080: 34762e42 3269704c 3888dfd6 05e80068 00000008 007f683a 10303120 2d204369
0a0: 7479206f 662e6d34 769f1dff 1b260090 ffff0030 007f683b 1e2e3032 202d204c
0c0: 6f6e656c 79204865 61727473 2e6d3476 2e61454e 59786913 1d7bf8ce 8c6200b0
0e0: 00000008 007f683b 16303220 2d204c6f 6e656c79 20486561 7274732e 6d34764a
100: 5eadac34 2b5d00e0 ffff0028 007f683c 1c2e3033 202d2049 6e207468 65204461
120: 726b2e6d 34762e7a 4b726254 72b50108 00000008 007f683c 14303320 2d20496e
140: 20746865 20446172 6b2e6d34 767b0130 ffff0030 007f683d 212e3034 202d2049
160: 2046616c 6c20746f 20506965 6365732e 6d34762e 6f735975 497aeb65 c2bb0150
180: 00000008 007f683d 19303420 2d204920 46616c6c 20746f20 50696563 65732e6d
1a0: 3476990e 3e560180 ffff0030 007f683e 1f2e3035 202d2052 6f6f6d20 77697468
1c0: 20612056 752e6d34 762e5478 72794b72 60a2e009 eef101a8 00000008 007f683e
1e0: 17303520 2d20526f 6f6d2077 69746820 61205675 2e6d3476 b883247d 552901d8
200: ffff0030 007f683f 242e3036 202d2053 656e7365 20262053 656e7369 74697669
220: 74792e6d 34762e65 6776556e 77550200 00000008 007f683f 1c303620 2d205365
240: 6e736520 26205365 6e736974 69766974 792e6d34 762b0230 ffff0030 0129b800
260: 1f2e3037 202d2042 61636865 6c6f7220 50617274 792e6d34 762e6632 4e477851
280: 7d4c7797 3f600258 00000008 0129b800 17303720 2d204261 6368656c 6f722050
2a0: 61727479 2e6d3476 4a911d34 eca00288 ffff0030 0129b801 242e3038 202d2049
2c0: 2057696c 6c205265 6d656d62 65722059 6f752e6d 34762e49 43687344 6ad002b0
2e0: 00000008 0129b801 1c303820 2d204920 57696c6c 2052656d 656d6265 7220596f
300: 752e6d34 76e902e0 ffff0020 0129b802 152e3039 202d2048 65726f2e 6d34762e
320: 58467063 36790308 00000008 0129b802 0d303920 2d204865 726f2e6d 34760328
340: ffff0030 0129b803 1e2e3130 202d2050 61727469 6e672047 69667473 2e6d3476
360: 2e794156 30534584 1783a6af dd270340 00000008 0129b803 16313020 2d205061
380: 7274696e 67204769 6674732e 6d347687 27f22157 cbc00370 ffff0028 0129b804
3a0: 1d2e3131 202d2053 6f6d6e61 6d62756c 6973742e 6d34762e 444d365a 6b760398
3c0: 00000008 0129b804 15313120 2d20536f 6d6e616d 62756c69 73742e6d 347603c0
3e0: ffff0028 0129b805 1a2e3132 202d2045 78706563 74696e67 2e6d3476 2e494b66
400: 6b3067c1 901903e0 00000008 0129b805 12313220 2d204578 70656374 696e672e
420: 6d3476db 2c390408 ffff0020 0129b806 142e3133 202d2053 68652e6d 34762e6a
440: 4c553742 50d30428 00000008 0129b806 0c313320 2d205368 652e6d34 76e10448
460: ffff0038 0129b807 2b2e3134 202d2049 27766520 476f7420 596f7520 556e6465
480: 72204d79 20536b69 6e2e6d34 762e4d74 4a536e70 86e50460 00000008 0129b807
4a0: 23313420 2d204927 76652047 6f742059 6f752055 6e646572 204d7920 536b696e
4c0: 2e6d3476 9d510498 ffff0028 0129b808 1d2e3135 202d2054 68652050 726f6469
4e0: 67616c2e 6d34762e 4879314f 704c04c8 00000008 0129b808 15313520 2d205468
500: 65205072 6f646967 616c2e6d 347604f0 ffff0028 0129b809 192e3136 202d2054
520: 68652052 696e672e 6d34762e 43764467 375aa0d3 c99e0510 00000008 0129b809
540: 11313620 2d205468 65205269 6e672e6d 3476181c c7aa0538 ffff0028 0129b80a
560: 192e3137 202d2045 7465726e 6974792e 6d34762e 48707449 625a34be fb360558
580: 00000008 0129b80a 11313720 2d204574 65726e69 74792e6d 3476cafa 1f2a0580
5a0: ffff0028 0129b80b 1d2e3138 202d2046 69766520 62792046 6976652e 6d34762e
5c0: 4d376f4b 703005a0 00000008 0129b80b 15313820 2d204669 76652062 79204669
5e0: 76652e6d 347605c8 ffff0028 0129b80c 1a2e3139 202d2053 616e6374 75617279
600: 2e6d3476 2e6a4b4c 514d4f4f 197a05e8 00000008 0129b80c 12313920 2d205361
620: 6e637475 6172792e 6d347638 4cbd0610 ffff0028 0129b80d 192e3230 202d2057
640: 6172205a 6f6e652e 6d34762e 45654333 39468f41 69da0630 00000008 0129b80d
660: 11323020 2d205761 72205a6f 6e652e6d 347627e8 12e20658 ffff0028 0129b80e
680: 1b2e3231 202d2042 6c696e64 20446174 652e6d34 762e3176 42307637 94160678
6a0: 00000008 0129b80e 13323120 2d20426c 696e6420 44617465 2e6d3476 0ec306a0
6c0: ffff0030 0129b80f 232e3232 202d2054 6f205368 616e7368 7520696e 204c2e41
6e0: 2e2e6d34 762e796b 35673178 b54306c0 00000008 0129b80f 1b323220 2d20546f
700: 20536861 6e736875 20696e20 4c2e412e 2e6d3476 288c06f0 ffff0020 0129b810
720: 132e7365 61736f6e 5f646f6e 652e6e43 616a3843 95690718 00000008 0129b810
740: 0b736561 736f6e5f 646f6e65 e16d0738 ffff07d0 f9ea06ea d5e36984 08dfaf37
760: 839b1911 0eb746af fcddf06e 0f80efea 2026141f 2745eb43 576864b0 9ed2d367
780: 6416bfd5 fd3fbe54 e92297c6 c270efcc 92bcd97f a65c797c 183f55ef 34a9a3c0
7a0: c8baae28 6ec2437e a1893396 953d1142 caa8f097 7bf24092 41761bd6 b0c9476f
7c0: 49feafe8 27befa39 337839fe 6cb36a71 02271bae efc1dd71 feb52c4b 86812ed3
7e0: 8796047e 0c56fca7 41e50a83 08caab90 44e09c44 128a8deb 53f0eeab 53b77cfb
800: 81ed5efa a63df170 1f7f1141 a5d3c9cf 396814b6 4e9e25fe 02bb6dec a53ad8d4
820: d0821508 4e9db912 93763d78 a8168589 03038a08 e0ca0726 7cd14047 5955481a
840: c4790009 219669b5 245a03a7 4432c8d7 75d11951 cf50c217 92c7ba29 6c0550e0
860: e62af66c be6f982d 10f973c9 eff4247a af474e28 596e66cf c4784950 4b8b2920
880: d1a86479 3bb122ce e7725d4f edcfd24e 873697d6 a32aa37a 50efecd4 5865ea8d
8a0: 2ab983d6 f7b5f8e9 1dd7da5c 25163ec5 f739efbb 1802ebee 130eedd2 acbe5057
8c0: 657a9441 e45944ec 81fccc2e fb195d01 08e27602 8c05d317 192d287e 1f6b6b44
8e0: 0ea3dac4 47a2220c 9bd0c05e d19f0084 9d29c842 2329ef6d ee5f1243 c888b2d7
900: 72684d4d 2480de9e 17d89b6e 94d1ae56 a6801086 2606f081 16fa1c53 33d31265
920: e981b683 334e4852 7333fb71 b6a61d88 214c8e96 9951983f e274c5cf 0df673b9
940: 2504e588 92166468 c6c797a1 8f5f19a1 3c361256 8d82a685 cc9ef823 ce5c1bf8
960: 1079cc0c 17a734c1 20827061 c411c62c 061cefd0 9c859dee 4a9f4054 871d4aaa
980: ba6f826f b04c7af4 04bad6d3 a496781a ebfe246f 8ebc0b06 159d8229 aebae34a
9a0: c6b2ade4 33464523 11f48dce 57012621 d78c8057 1d1f46f4 2a18a7f5 154ee854
9c0: e26663de ce93d67e 1ebb438a 3a5e7676 a3a23975 3e230af3 675493ca 0c037437
9e0: 4b616411 0957bc98 d6a4e884 3e6cbc40 8d73ff32 70511f83 63412623 97c86e08
a00: aa4a81ec f63eb667 cc9d08d9 ad5587d3 bd633843 8bdc0dd5 082278c6 51a0bfcb
a20: 516674cf 1a21edcf d637719e c0c2611a 3b704840 187e86bd 1588453c e0dce6c2
a40: 72a96f83 80d9c4eb eb8cf0dc aa446e69 d52ebf6a 05f72c6f a699c103 0c9815d1
a60: 970a51cc d6624f7a d15b82bc 8d3e9dad 3faa9538 27def54a 028922fc 38286c39
a80: 71c7a014 e0eded3a 0a690907 7388c60b c6b67887 6b902d4e 21ca8aeb 7a4c5f65
aa0: 765eadca e2659fce 83f3c782 d52eb4b3 80d14192 96370abe 877069d8 fb3556ca
ac0: f3e9c2ad 8b8feaf2 40d369f7 7e47554e 66702687 b3111b33 e5ad2674 5688172c
ae0: 3a3a0fd1 8423c871 edf5ffab fd8a4b5c 2f01203f 450a34d1 fdb3f703 812a7acd
b00: f46e1c28 de90fa2a ec07adfc 9609447f 958c5b2a b0ed662f 0d8deba4 c2435873
b20: 16a9b9f6 6fa8663c 44027b36 985464c4 efac6073 28dbc000 79e617e9 a10f883a
b40: 4b44c78f 55ab9384 187180c5 2db10f43 b0d9a0fe c1bc615f 052b89a7 89f8739a
b60: e51b96c9 8a76ea67 6fbf1ba5 077d2a08 3dad2b88 e17d6c4e 6a553913 2c6fa5d1
b80: 2b6bf4bc 01c82612 1ebd3150 290dab97 b2fa8a81 1d29d75f a13a2c5e 74944ff6
ba0: a1530f5f 79426a7d d491c2f0 f93639aa 1f67ae3c 8274b8a8 b4b79706 3539bde3
bc0: 7be2d58c 49875f20 cc314f03 33aaef61 cda9405d ff044415 fd150822 faa4f257
be0: d4ed221a 5d5a8ce4 200e2e9c 96fccaad 4bba9f8b 253448a1 2de101f9 4916a536
c00: 725f39cc b7aaab5a 5c76965b e4009b17 0e0d53e4 d40d169b d4028a52 116ce300
c20: f2b43ec9 ef7bf8fe dc9a0b18 18b33c79 5d7d17ff d4db5b05 5e78ddbe 15b21957
c40: 0cc1085b 2bb4784f 7ed53bb0 75b0f0b0 556d9dc1 59a25bca 39360281 496b7e29
c60: 057cdf54 d6bd1f0c 53d799a7 5546023d c4705471 ae45c65b 6293ef94 6d691cc3
c80: a639d85c e30a2c1b 55f8c1ea 2039f040 e7cee649 610e07cc d54727ce 69e1106d
ca0: 009d124c c4549462 bce84f03 cffd7cb2 15f84246 9f07d1cf 0868c871 911061d9
cc0: 6e46283e 3a27cab5 f9cb1ca9 54699f02 998fd95e 264df0ef 569c1493 fe01fd0a
ce0: eff15169 34bd36cc b5dc5191 ef90312d 65ae1a21 349ce3f1 cbe326ae cc0bb2a7
d00: 1bfa7b64 a220c6a6 4082321c f9941053 ea9dc196 cff261d0 5874801f 6b2924b6
d20: 86dce448 532071af f4d7f789 c7eb7853 27a6e68c e1bfd039 0c7edc86 58cf2529
d40: 1b018742 3634a552 9349bf37 4052e265 a39e4c76 9f82e539 7e04a1d0 25b2c962
d60: af93a551 99ebcd67 36371b9f 653dc4d5 64082e7b 5418806e 0a1f520b c3760072
d80: eafc4c5a acebbcef 0001e2c5 0e60368a 58291704 cb6f1135 57e8bd7f aac906db
da0: df3d7989 f1036a7f 654b967e 633953db a05e60b4 fd5f48e2 867275a4 040f0928
dc0: ed385b29 bf0b2d96 eef904bc 9b695030 3cadcc76 ad48c64a f44c7350 b5087bda
de0: 23162a13 9326ada9 40982285 90862b55 ce7e1b1e 032a1b80 fc6a38b1 e3366816
e00: 2f64457a 250baa07 073a83f5 cde75e52 2b6a288e bc579c34 c3be59f9 c692e1cb
e20: 12c6452f a869827c b2eeeaf9 f61ca991 45625e17 f1eb5b64 cc56633b aad11127
e40: 7efa415e 4e63c788 1e53815a 9a3deed8 164c95f4 0e8c08e6 1f491f9a 674d8896
e60: 2a658a0c 3869bb6d 7ce3df75 141daf64 d0118632 5e770c85 43a05783 b8dca76e
e80: 7f400acf 65cb07a4 f79b2e57 76c9132c eb0c2466 4f2c3785 37359252 86fc1e04
ea0: cbce2311 b62986ad 632365c3 38f2d301 979cbb61 cd10b57a bce9f49e d475721a
ec0: 4b66eaae 6b0d7314 7076c4d1 424dd11e ba955554 db9fbd69 a28407e0 2b86a30d
ee0: 3680f9fc e58c9607 4077e015 a58184a3 56eace9e 9f124bb5 944a1b3c 897ad88d
f00: c2545a63 74d9659d d5af8264 4399a397 68d0a8c7 f7f59cb5 faf8f9db 133b0750
f20: 0000002e 00000002 0000172e 00000004 0d3b2e62 000000b0 1052379a 0000000a
f40: 15fe1de6 00000000 1d7c54e2 000000e7 1da526c4 0000009e 1f127df8 000000cb
f60: 2f384255 0000001c 3b0eaf4a 00000051 4040055a 00000046 484d370f 00000078
f80: 54f0b050 0000005c 55e13fd3 000000b9 560de5f6 00000065 68b5d9ab 00000093
fa0: 789cb9e0 00000089 7eb5a6e5 000000c2 88dfa187 00000081 8aa13ee8 0000003b
fc0: 93fda139 00000012 a56edfc1 0000006e b7310079 00000026 bf010bb3 000000a7
fe0: e956d990 00000030 f909f282 000000de fb7fbced 000000d4 0000001b 00000001
xfs_db> type dir2
xfs_db> p
bhdr.magic = 0x58443242
bhdr.bestfree[0].offset = 0x750
bhdr.bestfree[0].length = 0x7d0
bhdr.bestfree[1].offset = 0x460
bhdr.bestfree[1].length = 0x38
bhdr.bestfree[2].offset = 0xb0
bhdr.bestfree[2].length = 0x30
bu[0].inumber = 34368088090
bu[0].namelen = 1
bu[0].name = "."
bu[0].tag = 0x10
bu[1].inumber = 53687093248
bu[1].namelen = 2
bu[1].name = ".."
bu[1].tag = 0x20
bu[2].freetag = 0xffff
bu[2].length = 0x20
bu[2].tag = 0x30
bu[3].inumber = 34368088121
bu[3].namelen = 9
bu[3].name = ".DS_Store"
bu[3].tag = 0x50
bu[4].freetag = 0xffff
bu[4].length = 0x28
bu[4].tag = 0x68
bu[5].inumber = 34368088122
bu[5].namelen = 16
bu[5].name = "01 - City of.m4v"
bu[5].tag = 0x90
bu[6].freetag = 0xffff
bu[6].length = 0x30
bu[6].tag = 0xb0
bu[7].inumber = 34368088123
bu[7].namelen = 22
bu[7].name = "02 - Lonely Hearts.m4v"
bu[7].tag = 0xe0
bu[8].freetag = 0xffff
bu[8].length = 0x28
bu[8].tag = 0x108
bu[9].inumber = 34368088124
bu[9].namelen = 20
bu[9].name = "03 - In the Dark.m4v"
bu[9].tag = 0x130
bu[10].freetag = 0xffff
bu[10].length = 0x30
bu[10].tag = 0x150
bu[11].inumber = 34368088125
bu[11].namelen = 25
bu[11].name = "04 - I Fall to Pieces.m4v"
bu[11].tag = 0x180
bu[12].freetag = 0xffff
bu[12].length = 0x30
bu[12].tag = 0x1a8
bu[13].inumber = 34368088126
bu[13].namelen = 23
bu[13].name = "05 - Room with a Vu.m4v"
bu[13].tag = 0x1d8
bu[14].freetag = 0xffff
bu[14].length = 0x30
bu[14].tag = 0x200
bu[15].inumber = 34368088127
bu[15].namelen = 28
bu[15].name = "06 - Sense & Sensitivity.m4v"
bu[15].tag = 0x230
bu[16].freetag = 0xffff
bu[16].length = 0x30
bu[16].tag = 0x258
bu[17].inumber = 34379249664
bu[17].namelen = 23
bu[17].name = "07 - Bachelor Party.m4v"
bu[17].tag = 0x288
bu[18].freetag = 0xffff
bu[18].length = 0x30
bu[18].tag = 0x2b0
bu[19].inumber = 34379249665
bu[19].namelen = 28
bu[19].name = "08 - I Will Remember You.m4v"
bu[19].tag = 0x2e0
bu[20].freetag = 0xffff
bu[20].length = 0x20
bu[20].tag = 0x308
bu[21].inumber = 34379249666
bu[21].namelen = 13
bu[21].name = "09 - Hero.m4v"
bu[21].tag = 0x328
bu[22].freetag = 0xffff
bu[22].length = 0x30
bu[22].tag = 0x340
bu[23].inumber = 34379249667
bu[23].namelen = 22
bu[23].name = "10 - Parting Gifts.m4v"
bu[23].tag = 0x370
bu[24].freetag = 0xffff
bu[24].length = 0x28
bu[24].tag = 0x398
bu[25].inumber = 34379249668
bu[25].namelen = 21
bu[25].name = "11 - Somnambulist.m4v"
bu[25].tag = 0x3c0
bu[26].freetag = 0xffff
bu[26].length = 0x28
bu[26].tag = 0x3e0
bu[27].inumber = 34379249669
bu[27].namelen = 18
bu[27].name = "12 - Expecting.m4v"
bu[27].tag = 0x408
bu[28].freetag = 0xffff
bu[28].length = 0x20
bu[28].tag = 0x428
bu[29].inumber = 34379249670
bu[29].namelen = 12
bu[29].name = "13 - She.m4v"
bu[29].tag = 0x448
bu[30].freetag = 0xffff
bu[30].length = 0x38
bu[30].tag = 0x460
bu[31].inumber = 34379249671
bu[31].namelen = 35
bu[31].name = "14 - I\'ve Got You Under My Skin.m4v"
bu[31].tag = 0x498
bu[32].freetag = 0xffff
bu[32].length = 0x28
bu[32].tag = 0x4c8
bu[33].inumber = 34379249672
bu[33].namelen = 21
bu[33].name = "15 - The Prodigal.m4v"
bu[33].tag = 0x4f0
bu[34].freetag = 0xffff
bu[34].length = 0x28
bu[34].tag = 0x510
bu[35].inumber = 34379249673
bu[35].namelen = 17
bu[35].name = "16 - The Ring.m4v"
bu[35].tag = 0x538
bu[36].freetag = 0xffff
bu[36].length = 0x28
bu[36].tag = 0x558
bu[37].inumber = 34379249674
bu[37].namelen = 17
bu[37].name = "17 - Eternity.m4v"
bu[37].tag = 0x580
bu[38].freetag = 0xffff
bu[38].length = 0x28
bu[38].tag = 0x5a0
bu[39].inumber = 34379249675
bu[39].namelen = 21
bu[39].name = "18 - Five by Five.m4v"
bu[39].tag = 0x5c8
bu[40].freetag = 0xffff
bu[40].length = 0x28
bu[40].tag = 0x5e8
bu[41].inumber = 34379249676
bu[41].namelen = 18
bu[41].name = "19 - Sanctuary.m4v"
bu[41].tag = 0x610
bu[42].freetag = 0xffff
bu[42].length = 0x28
bu[42].tag = 0x630
bu[43].inumber = 34379249677
bu[43].namelen = 17
bu[43].name = "20 - War Zone.m4v"
bu[43].tag = 0x658
bu[44].freetag = 0xffff
bu[44].length = 0x28
bu[44].tag = 0x678
bu[45].inumber = 34379249678
bu[45].namelen = 19
bu[45].name = "21 - Blind Date.m4v"
bu[45].tag = 0x6a0
bu[46].freetag = 0xffff
bu[46].length = 0x30
bu[46].tag = 0x6c0
bu[47].inumber = 34379249679
bu[47].namelen = 27
bu[47].name = "22 - To Shanshu in L.A..m4v"
bu[47].tag = 0x6f0
bu[48].freetag = 0xffff
bu[48].length = 0x20
bu[48].tag = 0x718
bu[49].inumber = 34379249680
bu[49].namelen = 11
bu[49].name = "season_done"
bu[49].tag = 0x738
bu[50].freetag = 0xffff
bu[50].length = 0x7d0
bu[50].tag = 0x750
bleaf[0].hashval = 0x2e
bleaf[0].address = 0x2
bleaf[1].hashval = 0x172e
bleaf[1].address = 0x4
bleaf[2].hashval = 0xd3b2e62
bleaf[2].address = 0xb0
bleaf[3].hashval = 0x1052379a
bleaf[3].address = 0xa
bleaf[4].hashval = 0x15fe1de6
bleaf[4].address = 0
bleaf[5].hashval = 0x1d7c54e2
bleaf[5].address = 0xe7
bleaf[6].hashval = 0x1da526c4
bleaf[6].address = 0x9e
bleaf[7].hashval = 0x1f127df8
bleaf[7].address = 0xcb
bleaf[8].hashval = 0x2f384255
bleaf[8].address = 0x1c
bleaf[9].hashval = 0x3b0eaf4a
bleaf[9].address = 0x51
bleaf[10].hashval = 0x4040055a
bleaf[10].address = 0x46
bleaf[11].hashval = 0x484d370f
bleaf[11].address = 0x78
bleaf[12].hashval = 0x54f0b050
bleaf[12].address = 0x5c
bleaf[13].hashval = 0x55e13fd3
bleaf[13].address = 0xb9
bleaf[14].hashval = 0x560de5f6
bleaf[14].address = 0x65
bleaf[15].hashval = 0x68b5d9ab
bleaf[15].address = 0x93
bleaf[16].hashval = 0x789cb9e0
bleaf[16].address = 0x89
bleaf[17].hashval = 0x7eb5a6e5
bleaf[17].address = 0xc2
bleaf[18].hashval = 0x88dfa187
bleaf[18].address = 0x81
bleaf[19].hashval = 0x8aa13ee8
bleaf[19].address = 0x3b
bleaf[20].hashval = 0x93fda139
bleaf[20].address = 0x12
bleaf[21].hashval = 0xa56edfc1
bleaf[21].address = 0x6e
bleaf[22].hashval = 0xb7310079
bleaf[22].address = 0x26
bleaf[23].hashval = 0xbf010bb3
bleaf[23].address = 0xa7
bleaf[24].hashval = 0xe956d990
bleaf[24].address = 0x30
bleaf[25].hashval = 0xf909f282
bleaf[25].address = 0xde
bleaf[26].hashval = 0xfb7fbced
bleaf[26].address = 0xd4
btail.count = 27
btail.stale = 1


Based on the file names that’s this, unaffected directory:

vera /mnt/media/TV/Angel 0$ ls Season\ 1
01 - City of.m4v              07 - Bachelor Party.m4v       13 - She.m4v                         19 - Sanctuary.m4v
02 - Lonely Hearts.m4v        08 - I Will Remember You.m4v  14 - I've Got You Under My Skin.m4v  20 - War Zone.m4v
03 - In the Dark.m4v          09 - Hero.m4v                 15 - The Prodigal.m4v                21 - Blind Date.m4v
04 - I Fall to Pieces.m4v     10 - Parting Gifts.m4v        16 - The Ring.m4v                    22 - To Shanshu in L.A..m4v
05 - Room with a Vu.m4v       11 - Somnambulist.m4v         17 - Eternity.m4v                    season_done
06 - Sense & Sensitivity.m4v  12 - Expecting.m4v            18 - Five by Five.m4v

I md5sum’d all those files against the last backup — they all seem fine, and listing and opening those files does not produce any kernel messages.

I tried a couple other addresses from the logs and got similar results — they all worked fine and were not related to the inaccessible paths.


> Hmmmm - you're not using LVM snapshots or anything like that are
> you?


No. Just a vanilla: `lvcreate -L 16T -n tv /dev/lvmsas`

And the filesystem has had very little activity since creation — I filed it from using rsync (converting from JFS after hitting the 32 TB limit on that filesystem) and 99% of the files are marked immutable.

	Zach


[-- Attachment #1.2: smime.p7s --]
[-- Type: application/pkcs7-signature, Size: 2749 bytes --]

[-- Attachment #2: Type: text/plain, Size: 121 bytes --]

_______________________________________________
xfs mailing list
xfs@oss.sgi.com
http://oss.sgi.com/mailman/listinfo/xfs

Re: Files with non-ASCII names inaccessible after xfs_repair

[Dave Chinner]

On Sun, Jan 12, 2014 at 07:47:29PM -0800, Zachary Kotlarek wrote:
> 
> On Jan 12, 2014, at 7:19 PM, Dave Chinner <david@fromorbit.com>
> wrote:
> 
> > IOWs, xfs-repair wrote new contents to those blocks, and now the
> > kernel cannot read them from disk.
> 
> 
> Sure, but I don’t understand why it would have re-written them
> in the first place. I know corruption happens, but this seems
> awfully pattern-tastic to be random errors.

Neither do I, but I'm trying to find out.

> > Try using xfs_db to read and parse the blocks that the
> > fielsystem is choking on. If it can't read them from xfs_db,
> > then there's something gone wrong below XFS. If you can read
> > them, use xfs_db to parse the block as a directory block and see
> > what the raw directory entries are the block contains....

Based on the xfs-db output, these warnings are not related to the
problem you are seeing. It's likely just a result of readahead being
cancelled due to load, and the error set by the DM layer not being
handled properly.

So, you need to find the inode number of a directory with a corrupt
entry, and dump the inode and any data fork blocks that it belongs
to with xfs_db similar to what you have just done. 

Cheers,

Dave.
-- 
Dave Chinner
david@fromorbit.com

_______________________________________________
xfs mailing list
xfs@oss.sgi.com
http://oss.sgi.com/mailman/listinfo/xfs

Re: Files with non-ASCII names inaccessible after xfs_repair

[Zachary Kotlarek]

[-- Attachment #1.1: Type: text/plain, Size: 18379 bytes --]


On Jan 13, 2014, at 11:27 AM, Dave Chinner <david@fromorbit.com> wrote:

> So, you need to find the inode number of a directory with a corrupt
> entry, and dump the inode and any data fork blocks that it belongs
> to with xfs_db similar to what you have just done. 


Got one. bu[9] is the file that doesn’t work:

xfs_db /dev/lvmsas/tv
xfs_db> inode 68719478806
xfs_db> p
core.magic = 0x494e
...
u.bmx[0] = [startoff,startblock,blockcount,extentflag] 0:[0,4294967423,1,0]
a.bmx[0] = [startoff,startblock,blockcount,extentflag] 0:[0,4294967537,1,0]
xfs_db> fsb 4294967423
xfs_db> p
000: 58443242 03980b88 00000000 00000000 00000010 00000816 012ee69d 215c0010
020: 00000002 00000800 022e2ea2 1dc60020 00000010 00000817 092e4453 5f53746f
040: 7265652e 726f0030 00000010 00000818 10303120 2d20446f 2d4f7665 722e6d34
060: 76657b54 75e80048 00000010 00000819 1d303220 2d204265 6c696576 6520696e
080: 20746865 20537461 72732e6d 34760068 00000010 0000081a 2d303320 2d205468
0a0: 65204f6e 65207769 74682074 68652043 61737420 6f66204e 69676874 20436f75
0c0: 72742e6d 34760090 00000010 0000081b 15303420 2d204761 76696e20 566f6c75
0e0: 72652e6d 347600c8 00000010 0000081c 10303520 2d205265 756e696f 6e2e6d34
100: 76732e6d 347600e8 00000010 0000081d 1a303620 2d204368 72697374 6d617320
120: 53706563 69616c2e 6d347674 206f0108 00000010 0000081e 1a303720 2d205365
140: c3b16f72 204d6163 686f2053 6f6c6f2e 6d347620 2d200130 00000010 0000081f
160: 11303820 2d20466c 75205368 6f742e6d 34766874 20430158 00000010 00000820
180: 20303920 2d205265 74726561 7420746f 204d6f76 6520466f 72776172 642e6d34
1a0: 76414e79 46490178 00000010 00000821 16313020 2d204765 6e657261 6c697373
1c0: 696d6f2e 6d3476a8 ffff0028 000001a8 00000010 00000822 1c313120 2d205374
1e0: 2e205661 6c656e74 696e6527 73204461 792e6d34 760001d0 00000010 00000823
200: 13313220 2d204c61 72727920 4b696e67 2e6d3476 000001f8 00000010 00000824
220: 1b313320 2d20476f 6f646279 652c204d 79204672 69656e64 2e6d3476 0add0218
240: 00000010 00000825 16313420 2d205468 65204675 6e636f6f 6b65722e 6d34762e
260: 6d34763a 84810240 00000010 00000826 13313520 2d205468 65204275 62626c65
280: 2e6d3476 536f0268 00000010 00000827 17313620 2d204170 6f6c6c6f 2c204170
2a0: 6f6c6c6f 2e6d3476 c3b16f72 204d0288 00000010 00000828 11313720 2d204375
2c0: 74626163 6b732e6d 34763038 202d02b0 00000010 00000829 1a313820 2d204a61
2e0: 636b6965 204a6f72 6d702d4a 6f6d702e 6d347620 2d2002d0 00000010 0000082a
300: 11313920 2d205468 65204f6e 65732e6d 34763039 202d02f8 00000010 0000082b
320: 1a323020 2d205468 65204e61 74757261 6c204f72 6465722e 6d34767b 44850318
340: 00000010 0000082c 12323120 2d204d61 6d6d6120 4d69612e 6d347676 65200340
360: 00000010 0000082d 14323220 2d204b69 646e6579 204e6f77 212e6d34 762d0360
380: 00000010 0000082e 0b736561 736f6e5f 646f6e65 48460380 ffff0b88 00000e4f
3a0: 1a303720 2d205365 c3b16f72 204d6163 686f2053 6f6c6f2e 6d34762e 6d340398
3c0: ffff0b60 b9ea03a0 ffff0030 00000822 242e3131 202d2053 742e2056 616c656e
3e0: 74696e65 27732044 61792e6d 34762e75 384d554e 6c0a03c8 00000010 00000822
400: 1c313120 2d205374 2e205661 6c656e74 696e6527 73204461 792e6d34 766c03f8
420: ffff0028 00000823 1b2e3132 202d204c 61727279 204b696e 672e6d34 762e6a65
440: 6d346167 ae670420 00000010 00000823 13313220 2d204c61 72727920 4b696e67
460: 2e6d3476 c5cd0448 ffff0030 00000824 232e3133 202d2047 6f6f6462 79652c20
480: 4d792046 7269656e 642e6d34 762e697a 48574e66 6ebe0468 00000010 00000824
4a0: 1b313320 2d20476f 6f646279 652c204d 79204672 69656e64 2e6d3476 06550498
4c0: ffff0030 00000825 1e2e3134 202d2054 68652046 756e636f 6f6b6572 2e6d3476
4e0: 2e546c46 37754e82 53830dea f02904c0 00000010 00000825 16313420 2d205468
500: 65204675 6e636f6f 6b65722e 6d3476c9 49d6c27e 862404f0 ffff0028 00000826
520: 1b2e3135 202d2054 68652042 7562626c 652e6d34 762e324e 756d6a55 3e2e0518
540: 00000010 00000826 13313520 2d205468 65204275 62626c65 2e6d3476 b8190540
560: ffff0030 00000827 1f2e3136 202d2041 706f6c6c 6f2c2041 706f6c6c 6f2e6d34
580: 762e7862 706b7578 6015c501 5df00560 00000010 00000827 17313620 2d204170
5a0: 6f6c6c6f 2c204170 6f6c6c6f 2e6d3476 207a805c 32f30590 ffff0028 00000828
5c0: 192e3137 202d2043 75746261 636b732e 6d34762e 38644241 4e4e95d2 df0c05b8
5e0: 00000010 00000828 11313720 2d204375 74626163 6b732e6d 3476bfa5 5c2d05e0
600: ffff0030 00000829 222e3138 202d204a 61636b69 65204a6f 726d702d 4a6f6d70
620: 2e6d3476 2e463654 536e4750 ed990600 00000010 00000829 1a313820 2d204a61
640: 636b6965 204a6f72 6d702d4a 6f6d702e 6d3476b3 568f0630 ffff0028 0000082a
660: 192e3139 202d2054 6865204f 6e65732e 6d34762e 5359636f 536c1450 7d780658
680: 00000010 0000082a 11313920 2d205468 65204f6e 65732e6d 347633f1 b79c0680
6a0: ffff0030 0000082b 222e3230 202d2054 6865204e 61747572 616c204f 72646572
6c0: 2e6d3476 2e4c7779 456e7607 1acd06a0 00000010 0000082b 1a323020 2d205468
6e0: 65204e61 74757261 6c204f72 6465722e 6d347620 6ac406d0 ffff0028 0000082c
700: 1a2e3231 202d204d 616d6d61 204d6961 2e6d3476 2e793774 444471f0 7afb06f8
720: 00000010 0000082c 12323120 2d204d61 6d6d6120 4d69612e 6d34764a c2a20720
740: ffff0028 0000082d 1c2e3232 202d204b 69646e65 79204e6f 77212e6d 34762e31
760: 70556e4a 516d0740 00000010 0000082d 14323220 2d204b69 646e6579 204e6f77
780: 212e6d34 76ec0768 ffff0020 0000082e 132e7365 61736f6e 5f646f6e 652e5942
7a0: 45707653 4b1b0788 00000010 0000082e 0b736561 736f6e5f 646f6e65 dc4e07a8
7c0: ffff0760 e25dfdec 236bc146 04c68637 7ab5e375 e452f5b4 aa68bbe2 e8f96e8c
7e0: 2873dc2b 8c11d44f 8102132b cd297ee7 96731e39 9ce20e24 8c720b52 9d268801
800: 6f35094c 840bffb0 ea57f284 4ed0ddce c5fe47bc b716c676 5dcf744d 6e1e043c
820: 65168783 12942365 473c4dd6 87b983ff b27554b6 ced9b37b 73a45143 953cfd5d
840: 776b8ce5 02b22034 12e3976a bf8ac0cf 6040f314 29a94c5d 1f64d68b 41522fae
860: 5d086649 b415c9bc 5033532f 67d82e68 aba29045 99d66c7d 7d27a726 2461fab8
880: 62ffcb2d 2aae50f0 8a14c75e fb120b7c 30a35fde a44fb8ef 50e8ba97 87cd173f
8a0: 665fa3fb 068b30b0 2eb54bda 500c30e3 0f32a030 3bc1e136 371908be 03be9608
8c0: 08931d14 19edb458 611be149 e69eab30 80885c83 ce31770c ef30d08f 047edd2b
8e0: 881cd519 7a01e6e4 6bda3ab0 007b9eeb c406b0bd bdaa3634 e6ad67e4 1a0cb40a
900: ee3f89b3 18361c80 bab39b25 765b2eeb dcdae533 632b1eaa 527169da 0808768c
920: 059a6327 60bfb867 64e6dfd1 c4790448 521e8b10 599e93ca 7ac96307 152793d1
940: 35e8539e 31c0a2ac b21c7fef b9c4b292 e76ea63d 2f5f4789 e996ba68 fc1f648a
960: f50cb772 6daa9cf9 29f49bc0 99450bdc e675a924 cd5df975 bbef5aca 6f7f6dda
980: e3cf4905 d362fabe ca2f55ac 416055f8 c4478efe 76af424f 1246495b 0681f743
9a0: 8985d4a8 c3bd705f b7fdad96 11e865b8 9d47709c 949269b7 171ba67c c0ecc834
9c0: 8720b834 f2265a2a 89cbab9f e1585a1e 0ad602bb fd403330 d1996c2b 1dbd6f02
9e0: 5a890263 74042c9e 793ad4f8 5cbf7e6c 93666ff9 6cbbf437 05e82d05 7f0a56d8
a00: 0bc2aacb 9072859c 732cad1a 16b6cf21 2ec91573 6026017c 4df2822a 7a8933f0
a20: 551195c5 fd7e2f03 aa07d4f3 f753314c eca96a08 d5aa1da7 fbe936d9 91e6b576
a40: 97d0c67c 5b46eabf df2292da b8536aab a12c6901 1ec450d8 18abacd6 1406d306
a60: 554371d9 8200daf2 284ad914 6ac1be9c 989fefc7 80b1cfa8 e73aec8c 221852ff
a80: 81fd770f cc436dcb c905bf19 c4f7a3e3 3cffa8d1 a6730bfb 23942b33 dfaeea27
aa0: 8b55cc38 09174831 7952c5c7 652fe34f ac4979c6 8e16a508 9ad307a5 8563bf20
ac0: a394d950 ea4d7801 6fd9ef09 c9755dcd 17109143 75a0fa3f ecf18c41 51b93a5e
ae0: 5e66abc4 d1dd1d42 8bf4f8dc 98fb592a 76491dcf 6387793d 0a7dfe57 358dc4a5
b00: 93fdbb04 e8586f2b 8edf9aa3 db46597d 6c9c1824 fa9f84f8 f192c630 dbf863d8
b20: a767867e 9e6155d0 f3a48ac9 47755639 1ea41778 032888b8 8d2bec2f 78196ed6
b40: 7fc54879 a7c28fb7 2385262d cebf16da d7723330 0d3666fd b6bd56f1 dc1e00d3
b60: 17a947ec 5e9dca3c d2fc6067 baf215e0 eb9783d1 89601c5b 7d82b2c7 5e66cb96
b80: 5e141c62 e821a2cc 80d7084c a5b77c29 5ec2586d 4b69b332 9549b233 38fc7b4d
ba0: 91bc57f6 566726bc 6dc234e4 0652f289 f40b37dc 721544c3 81ee4ee0 ebed6891
bc0: 4ac9351e f3283873 966d3e49 ad24e115 ee1d804c 70eaa426 ba1c48e6 7eafc96b
be0: c504f521 385b29ab 3532993f 266af82d 59ec08f9 d85820f3 589cc633 ee41a655
c00: a99d074d 23d8823e e7508910 16cc9d9c cecb5cb9 81de6036 b4e8faba cfdbdaf6
c20: 36536522 d057ff4a b9e85de3 f7b2704c 9a4908ca e339ac32 d785c548 348daa6a
c40: f0afc265 a71c920b 50ae9757 0b51af96 34531279 4da1ee1f f9df3e83 0055f97e
c60: 65fe66b4 34399905 9784127e 4c255ddd b0334416 fa5ef3d0 c62ab6aa f529f684
c80: e9ef32cd f1d11c0b ae35c00a 10e517fa 003f657c 3f6cb6e5 601b85ad 0d576c38
ca0: 794e5372 08c0bf34 1c895e11 b6fa2895 67437581 3400a236 f642fe70 a69faaf7
cc0: 819bdd30 a8219dbc 2d0e0523 a6fa62be 1aa2386b 1590a568 3e3da633 6f9808b0
ce0: 88b35ef6 14240b49 e6721f51 77cee9c3 1af382ab 01677e4d f090c4fa 4da2c2c5
d00: 024c8629 2ad08aa7 422af8e0 f9712ed5 177bdeea c25eabe2 729067c4 96c38d4f
d20: 7d12c96b b0d47cb4 153d0de0 b61116b9 05db3add 580b09ec 4185a57a 12d2f403
d40: a79875a9 869ed8e9 54496e3a 12409817 29d8a734 c250f847 0269266a b1d21578
d60: 929e6a00 84a2c798 8a7dbe54 c56d38f8 cd2c9928 e37d988e 86e3bbd3 d66a8fb5
d80: 95bbf81a 31ec0870 354a6694 e583a8df 4c75d417 079d9277 4739253a 88c7a85c
da0: ead4d046 c16f24a1 aac656b1 b1231730 292ad144 09d48770 9e383b4a 79ff74d9
dc0: b8453a71 687b98a3 d66e6948 782ff312 e6acc0ef 23bf3730 fa77b629 00e0c284
de0: 3e1394c0 dd947b2f 7acd855f d1b55dc6 dddcb637 4afcf856 b28caf57 b169fd76
e00: 02f996ac 93f1b65c fd365b9f 723f2848 ce77021d 0f3e1303 273bbf86 284e60ea
e20: aaf5b695 10fd5132 c91a16d0 11a41dc9 5a02186a bbbb94a0 7bbceef5 9e943106
e40: afb9aace 1933d188 6bf0727f 90aa9123 2241a0d0 01598503 cfabe4aa b00afb9b
e60: 3effbd69 68165260 f8a81102 d38b3878 cdd4e4cb 8618f097 42244acf b8b976cb
e80: 35125209 f7b5805e 40db397b 00abcfa9 8a50409a c0f51dcf abe9fb4d 5b8c44bb
ea0: ab9cc478 591f0715 5c06faff 4ff7c649 25880591 9d0f5e5c 7d38d25c 76648e19
ec0: 6f6bad24 2a754c82 3154a2e3 d43e803a 7ca54600 fd6a3f1a 90dfc856 4d3aba0d
ee0: ea944aec ca997066 341ad794 ed5b0d0d d1b95bbd f94ac17a 34df90af 8d8078e0
f00: 59d8b643 78da3fa9 c79a7dd6 a964a724 7ac02075 4ca9318d c21b6890 a9640398
f20: 0000002e 00000002 0000172e 00000004 00624cc3 00000063 1052379a 00000006
f40: 12d2816f 0000001d 16d07074 00000026 16d0707c 00000000 1d7c54e2 00000070
f60: 2caf2876 0000000d 3d25c6d2 00000056 3e07609a 0000005a 6b667b53 0000006c
f80: 78fc099c 00000035 8ad0f8ab 00000009 8c17559b 00000012 8f0052b2 0000002b
fa0: 8fc97221 00000043 931912cb 0000003a 96b3bb3b 00000051 9a3c8cd4 00000019
fc0: 9d95db76 00000048 aec5036b 00000021 dc3223ae 0000004d dd98adc4 0000002f
fe0: ea32fb33 0000003f eb7796fb 00000068 ff3b09ea 0000005f 0000001b 00000001
xfs_db> type dir2
xfs_db> p
bhdr.magic = 0x58443242
bhdr.bestfree[0].offset = 0x398
bhdr.bestfree[0].length = 0xb88
bhdr.bestfree[1].offset = 0
bhdr.bestfree[1].length = 0
bhdr.bestfree[2].offset = 0
bhdr.bestfree[2].length = 0
bu[0].inumber = 68719478806
bu[0].namelen = 1
bu[0].name = "."
bu[0].tag = 0x10
bu[1].inumber = 8589936640
bu[1].namelen = 2
bu[1].name = ".."
bu[1].tag = 0x20
bu[2].inumber = 68719478807
bu[2].namelen = 9
bu[2].name = ".DS_Store"
bu[2].tag = 0x30
bu[3].inumber = 68719478808
bu[3].namelen = 16
bu[3].name = "01 - Do-Over.m4v"
bu[3].tag = 0x48
bu[4].inumber = 68719478809
bu[4].namelen = 29
bu[4].name = "02 - Believe in the Stars.m4v"
bu[4].tag = 0x68
bu[5].inumber = 68719478810
bu[5].namelen = 45
bu[5].name = "03 - The One with the Cast of Night Court.m4v"
bu[5].tag = 0x90
bu[6].inumber = 68719478811
bu[6].namelen = 21
bu[6].name = "04 - Gavin Volure.m4v"
bu[6].tag = 0xc8
bu[7].inumber = 68719478812
bu[7].namelen = 16
bu[7].name = "05 - Reunion.m4v"
bu[7].tag = 0xe8
bu[8].inumber = 68719478813
bu[8].namelen = 26
bu[8].name = "06 - Christmas Special.m4v"
bu[8].tag = 0x108
bu[9].inumber = 68719478814
bu[9].namelen = 26
bu[9].name = "07 - Se\303\261or Macho Solo.m4v"
bu[9].tag = 0x130
bu[10].inumber = 68719478815
bu[10].namelen = 17
bu[10].name = "08 - Flu Shot.m4v"
bu[10].tag = 0x158
bu[11].inumber = 68719478816
bu[11].namelen = 32
bu[11].name = "09 - Retreat to Move Forward.m4v"
bu[11].tag = 0x178
bu[12].inumber = 68719478817
bu[12].namelen = 22
bu[12].name = "10 - Generalissimo.m4v"
bu[12].tag = 0x1a8
bu[13].inumber = 68719478818
bu[13].namelen = 28
bu[13].name = "11 - St. Valentine\'s Day.m4v"
bu[13].tag = 0x1d0
bu[14].inumber = 68719478819
bu[14].namelen = 19
bu[14].name = "12 - Larry King.m4v"
bu[14].tag = 0x1f8
bu[15].inumber = 68719478820
bu[15].namelen = 27
bu[15].name = "13 - Goodbye, My Friend.m4v"
bu[15].tag = 0x218
bu[16].inumber = 68719478821
bu[16].namelen = 22
bu[16].name = "14 - The Funcooker.m4v"
bu[16].tag = 0x240
bu[17].inumber = 68719478822
bu[17].namelen = 19
bu[17].name = "15 - The Bubble.m4v"
bu[17].tag = 0x268
bu[18].inumber = 68719478823
bu[18].namelen = 23
bu[18].name = "16 - Apollo, Apollo.m4v"
bu[18].tag = 0x288
bu[19].inumber = 68719478824
bu[19].namelen = 17
bu[19].name = "17 - Cutbacks.m4v"
bu[19].tag = 0x2b0
bu[20].inumber = 68719478825
bu[20].namelen = 26
bu[20].name = "18 - Jackie Jormp-Jomp.m4v"
bu[20].tag = 0x2d0
bu[21].inumber = 68719478826
bu[21].namelen = 17
bu[21].name = "19 - The Ones.m4v"
bu[21].tag = 0x2f8
bu[22].inumber = 68719478827
bu[22].namelen = 26
bu[22].name = "20 - The Natural Order.m4v"
bu[22].tag = 0x318
bu[23].inumber = 68719478828
bu[23].namelen = 18
bu[23].name = "21 - Mamma Mia.m4v"
bu[23].tag = 0x340
bu[24].inumber = 68719478829
bu[24].namelen = 20
bu[24].name = "22 - Kidney Now!.m4v"
bu[24].tag = 0x360
bu[25].inumber = 68719478830
bu[25].namelen = 11
bu[25].name = "season_done"
bu[25].tag = 0x380
bu[26].freetag = 0xffff
bu[26].length = 0xb88
bu[26].tag = 0x398
bleaf[0].hashval = 0x2e
bleaf[0].address = 0x2
bleaf[1].hashval = 0x172e
bleaf[1].address = 0x4
bleaf[2].hashval = 0x624cc3
bleaf[2].address = 0x63
bleaf[3].hashval = 0x1052379a
bleaf[3].address = 0x6
bleaf[4].hashval = 0x12d2816f
bleaf[4].address = 0x1d
bleaf[5].hashval = 0x16d07074
bleaf[5].address = 0x26
bleaf[6].hashval = 0x16d0707c
bleaf[6].address = 0
bleaf[7].hashval = 0x1d7c54e2
bleaf[7].address = 0x70
bleaf[8].hashval = 0x2caf2876
bleaf[8].address = 0xd
bleaf[9].hashval = 0x3d25c6d2
bleaf[9].address = 0x56
bleaf[10].hashval = 0x3e07609a
bleaf[10].address = 0x5a
bleaf[11].hashval = 0x6b667b53
bleaf[11].address = 0x6c
bleaf[12].hashval = 0x78fc099c
bleaf[12].address = 0x35
bleaf[13].hashval = 0x8ad0f8ab
bleaf[13].address = 0x9
bleaf[14].hashval = 0x8c17559b
bleaf[14].address = 0x12
bleaf[15].hashval = 0x8f0052b2
bleaf[15].address = 0x2b
bleaf[16].hashval = 0x8fc97221
bleaf[16].address = 0x43
bleaf[17].hashval = 0x931912cb
bleaf[17].address = 0x3a
bleaf[18].hashval = 0x96b3bb3b
bleaf[18].address = 0x51
bleaf[19].hashval = 0x9a3c8cd4
bleaf[19].address = 0x19
bleaf[20].hashval = 0x9d95db76
bleaf[20].address = 0x48
bleaf[21].hashval = 0xaec5036b
bleaf[21].address = 0x21
bleaf[22].hashval = 0xdc3223ae
bleaf[22].address = 0x4d
bleaf[23].hashval = 0xdd98adc4
bleaf[23].address = 0x2f
bleaf[24].hashval = 0xea32fb33
bleaf[24].address = 0x3f
bleaf[25].hashval = 0xeb7796fb
bleaf[25].address = 0x68
bleaf[26].hashval = 0xff3b09ea
bleaf[26].address = 0x5f
btail.count = 27
btail.stale = 1

And the inode it lists, which has reasonable mtime and size based on similar files in the directory:

xfs_db> inode 68719478814
xfs_db> p
core.magic = 0x494e
core.mode = 0100660
core.version = 2
core.format = 2 (extents)
core.nlinkv2 = 1
core.onlink = 0
core.projid_lo = 0
core.projid_hi = 0
core.uid = 1000
core.gid = 100
core.flushiter = 368
core.atime.sec = Thu Jan  2 18:23:36 2014
core.atime.nsec = 082260304
core.mtime.sec = Sat Sep 11 20:13:07 2010
core.mtime.nsec = 000000000
core.ctime.sec = Sun Jan 12 01:30:25 2014
core.ctime.nsec = 866103023
core.size = 326451171
core.nblocks = 79700
core.extsize = 0
core.nextents = 1
core.naextents = 0
core.forkoff = 7
core.aformat = 1 (local)
core.dmevmask = 0
core.dmstate = 0
core.newrtbm = 0
core.prealloc = 0
core.realtime = 0
core.immutable = 1
core.append = 0
core.sync = 0
core.noatime = 0
core.nodump = 0
core.rtinherit = 0
core.projinherit = 0
core.nosymlinks = 0
core.extsz = 0
core.extszinherit = 0
core.nodefrag = 0
core.filestream = 0
core.gen = 2502109681
next_unlinked = null
u.bmx[0] = [startoff,startblock,blockcount,extentflag] 0:[0,509696,79700,0]
a.sfattr.hdr.totsize = 95
a.sfattr.hdr.count = 1
a.sfattr.list[0].namelen = 12
a.sfattr.list[0].valuelen = 76
a.sfattr.list[0].root = 1
a.sfattr.list[0].secure = 0
a.sfattr.list[0].name = "SGI_ACL_FILE"
a.sfattr.list[0].value = "\000\000\000\006\000\000\000\001\377\377\377\377\000\006\000\000\000\000\000\004\377\377\377\377\000\006\000\000\000\000\000\b\000\000\000d\000\006\000\000\000\000\000\b\000\000\003\361\000\004\000\000\000\000\000\020\377\377\377\377\000\006\000\000\000\000\000 \377\377\377\377\000\000\000\000”

I’m not sure if this the right way to get the related first data block. If I did it wrong let me know:

xfs_db> daddr 509696
xfs_db> p
000: e85e996a 4e705067 b42c65f1 97d553b3 4af10990 1609bbd9 beeef165 f1cf1a2c
020: 483f0a2e 24ecce2e ff1aa9bc a8e3b359 0808858e f7db2c32 d163ef30 10782a0e
040: 82862ec9 22285fed 90177e6e f8d2b6d2 15ae9d85 35356190 bffc2604 3ec17ea8
060: bb69e2ba 6ffd82ed b5df455d 4f2ed5bf 042b87c8 2a457ad3 224eb183 4905d39f
080: 37d5acb5 28480b63 c32662c6 33bd3c51 3de5ca43 bf7639c9 fa1097c1 8a1aff22
0a0: 9af51d18 89455c57 c569eb0c 8790d635 54e7ea81 9a37fd0b 824d57d6 6fb28c79
0c0: 6ba742db cf65ffd7 f47ef4f2 7f7e0233 fa2f788f e09d5aef 7cb17105 eddf901e
0e0: 21a74f60 c7c19141 387289a9 514d8962 2fb8597c 0a806421 6920a244 8610318f
100: f1119976 46332bd6 aad56bc2 319e7e23 e6b559c5 8aabf1e9 26c50da8 806048fd
120: 7851b307 6a858007 21c1feb2 4281f277 5fc5dd9b e49b59db 7f209de1 66d9e02b
140: ac4ca898 1dfeff12 207ec7cd 83283cf0 6f9d24be 421f64bc ffd05e4d e3828501
160: 0809baac 56a9dfc4 2133bbee fcd0d1e9 1c00f07d ecfec298 ead947e9 06ba929c
180: 7a3206f2 7efe3450 28cbf76a cf99e170 a22bf86d 826dade6 d67f8e60 6d5c7c02
1a0: 94be0967 ab263252 9ff805b1 7b34db8f 9a099feb cdb274e2 a06cd03f cbf8aefe
1c0: 7128dacb fad4c84c 63c4d19f 27a836fe 2a5ad1cb e8e6afe1 5f7c8182 9f46dcfd
1e0: 3a475df5 f9a1dc40 9f51fedd d722ef07 6e2346e9 8d58b1dd 8c7e9d7c 041826cf

Thanks for your help,
	Zach


[-- Attachment #1.2: smime.p7s --]
[-- Type: application/pkcs7-signature, Size: 2749 bytes --]

[-- Attachment #2: Type: text/plain, Size: 121 bytes --]

_______________________________________________
xfs mailing list
xfs@oss.sgi.com
http://oss.sgi.com/mailman/listinfo/xfs

Re: Files with non-ASCII names inaccessible after xfs_repair

[Dave Chinner]

On Mon, Jan 13, 2014 at 03:07:30PM -0800, Zachary Kotlarek wrote:
> 
> On Jan 13, 2014, at 11:27 AM, Dave Chinner <david@fromorbit.com> wrote:
> 
> > So, you need to find the inode number of a directory with a corrupt
> > entry, and dump the inode and any data fork blocks that it belongs
> > to with xfs_db similar to what you have just done. 
> 
> 
> Got one. bu[9] is the file that doesn’t work:
.....
> bu[9].inumber = 68719478814
> bu[9].namelen = 26
> bu[9].name = "07 - Se\303\261or Macho Solo.m4v"
> bu[9].tag = 0x130

That looks completely valid. It's a utf-8 encoded directory entry.
It doesn't look like there's any corruption on disk here.

The ls -l output full of ???? usually means the stat of the inode
the dirent pointed to, so that implies that the stat has failed.
So, what does and strace of the 'ls -l' of that directory tell you
about the directory entry that is returned to userspace?

> bleaf[5].hashval = 0x16d07074
> bleaf[5].address = 0x26

That's the hash entry in the directory for the name. That may be
wrong, I guess. can you create another file with the same name
in a different directory so we can check that the hash is correct?

> u.bmx[0] = [startoff,startblock,blockcount,extentflag] 0:[0,509696,79700,0]
> 
> I’m not sure if this the right way to get the related first data block. If I did it wrong let me know:
> 
> xfs_db> daddr 509696

fsb 509696, not daddr.

Cheers,

Dave.

-- 
Dave Chinner
david@fromorbit.com

_______________________________________________
xfs mailing list
xfs@oss.sgi.com
http://oss.sgi.com/mailman/listinfo/xfs

Re: Files with non-ASCII names inaccessible after xfs_repair

[Zachary Kotlarek]

[-- Attachment #1.1: Type: text/plain, Size: 2717 bytes --]


On Jan 13, 2014, at 6:24 PM, Dave Chinner <david@fromorbit.com> wrote:

>> Got one. bu[9] is the file that doesn’t work:
> .....
>> bu[9].inumber = 68719478814
>> bu[9].namelen = 26
>> bu[9].name = "07 - Se\303\261or Macho Solo.m4v"
>> bu[9].tag = 0x130
> 
> That looks completely valid. It's a utf-8 encoded directory entry.
> It doesn't look like there's any corruption on disk here.
> 
> The ls -l output full of ???? usually means the stat of the inode
> the dirent pointed to, so that implies that the stat has failed.
> So, what does and strace of the 'ls -l' of that directory tell you
> about the directory entry that is returned to userspace?


It just returns ENOENT:
stat("/mnt/media/TV/30 Rock/Season 3/07 - Señor Macho Solo.m4v", 0x15990f0) = -1 ENOENT (No such file or directory)
lstat("/mnt/media/TV/30 Rock/Season 3/07 - Señor Macho Solo.m4v", 0x15990f0) = -1 ENOENT (No such file or directory)


>> bleaf[5].hashval = 0x16d07074
>> bleaf[5].address = 0x26
> 
> That's the hash entry in the directory for the name. That may be
> wrong, I guess. can you create another file with the same name
> in a different directory so we can check that the hash is correct?


bu[16].inumber = 9255716888
bu[16].namelen = 26
bu[16].name = "07 - Se\303\261or Macho Solo.m4v"
bu[16].tag = 0x1d8

I don’t understand how to find the right bleaf, but 0x16d07074 doesn’t appear in any of the hashvals for that directory:

bleaf[0].hashval = 0x2e
bleaf[0].address = 0x2
bleaf[1].hashval = 0x172e
bleaf[1].address = 0x4
bleaf[2].hashval = 0x1052379a
bleaf[2].address = 0x22
bleaf[3].hashval = 0x16d0707c
bleaf[3].address = 0x3b
bleaf[4].hashval = 0x3d1c0738
bleaf[4].address = 0x1b
bleaf[5].hashval = 0x3d1c0739
bleaf[5].address = 0x18
bleaf[6].hashval = 0x3d1c073a
bleaf[6].address = 0x15
bleaf[7].hashval = 0x3d1c073b
bleaf[7].address = 0x12
bleaf[8].hashval = 0x3d1c073c
bleaf[8].address = 0xf
bleaf[9].hashval = 0x3d1c073d
bleaf[9].address = 0xc
bleaf[10].hashval = 0x3d1c073e
bleaf[10].address = 0x9
bleaf[11].hashval = 0x3d1c073f
bleaf[11].address = 0x6
bleaf[12].hashval = 0x7f92e42b
bleaf[12].address = 0x2b
bleaf[13].hashval = 0x9f92e6c0
bleaf[13].address = 0x36


>> u.bmx[0] = [startoff,startblock,blockcount,extentflag] 0:[0,509696,79700,0]
>> 
>> I’m not sure if this the right way to get the related first data block. If I did it wrong let me know:
>> 
>> xfs_db> daddr 509696
> 
> fsb 509696, not daddr.


xfs_db> fsb 509696 
xfs_db> p
000: 0000001c 66747970 6d703432 00000000 6d703432 69736f6d 61766331 00000084

And that looks like the MP4 magic number across the first 3 segments, which is what I’m expecting.

	Zach


[-- Attachment #1.2: smime.p7s --]
[-- Type: application/pkcs7-signature, Size: 2749 bytes --]

[-- Attachment #2: Type: text/plain, Size: 121 bytes --]

_______________________________________________
xfs mailing list
xfs@oss.sgi.com
http://oss.sgi.com/mailman/listinfo/xfs

Re: Files with non-ASCII names inaccessible after xfs_repair

[Dave Chinner]

On Mon, Jan 13, 2014 at 07:12:07PM -0800, Zachary Kotlarek wrote:
> 
> On Jan 13, 2014, at 6:24 PM, Dave Chinner <david@fromorbit.com> wrote:
> 
> >> Got one. bu[9] is the file that doesn’t work:
> > .....
> >> bu[9].inumber = 68719478814
> >> bu[9].namelen = 26
> >> bu[9].name = "07 - Se\303\261or Macho Solo.m4v"
> >> bu[9].tag = 0x130
> > 
> > That looks completely valid. It's a utf-8 encoded directory entry.
> > It doesn't look like there's any corruption on disk here.
> > 
> > The ls -l output full of ???? usually means the stat of the inode
> > the dirent pointed to, so that implies that the stat has failed.
> > So, what does and strace of the 'ls -l' of that directory tell you
> > about the directory entry that is returned to userspace?
> 
> It just returns ENOENT:
> stat("/mnt/media/TV/30 Rock/Season 3/07 - Señor Macho Solo.m4v", 0x15990f0) = -1 ENOENT (No such file or directory)
> lstat("/mnt/media/TV/30 Rock/Season 3/07 - Señor Macho Solo.m4v", 0x15990f0) = -1 ENOENT (No such file or directory)

Ok, so it's a lookup failure.

> >> bleaf[5].hashval = 0x16d07074
> >> bleaf[5].address = 0x26
> > 
> > That's the hash entry in the directory for the name. That may be
> > wrong, I guess. can you create another file with the same name
> > in a different directory so we can check that the hash is correct?
> 
> bu[16].inumber = 9255716888
> bu[16].namelen = 26
> bu[16].name = "07 - Se\303\261or Macho Solo.m4v"
> bu[16].tag = 0x1d8
> 
> I don’t understand how to find the right bleaf, but 0x16d07074 doesn’t appear in any of the hashvals for that directory:

Pretty simple - the leaf[].address is simply a compressed offset
into the leaf. all dirents are 8 byte aligned, and the tag is the
byte offset into the leaf dirent space. Hence:

	leaf[].address = bu[16].tag >> 3
			= 0x1d8 >> 3
			= 0x3b
			= bleaf[3].address

> bleaf[3].hashval = 0x16d0707c
> bleaf[3].address = 0x3b

And there were are - there's a single bit discrepancy in the lower
byte of the hash. That tends to imply we have a bug in xfs_repair.

What version of xfs_repair did you use? (xfs_repair -V)

Cheers,

Dave.
-- 
Dave Chinner
david@fromorbit.com

_______________________________________________
xfs mailing list
xfs@oss.sgi.com
http://oss.sgi.com/mailman/listinfo/xfs

Re: Files with non-ASCII names inaccessible after xfs_repair

[Zachary Kotlarek]

[-- Attachment #1.1: Type: text/plain, Size: 738 bytes --]


On Jan 14, 2014, at 5:53 PM, Dave Chinner <david@fromorbit.com> wrote:

> Pretty simple - the leaf[].address is simply a compressed offset
> into the leaf. all dirents are 8 byte aligned, and the tag is the
> byte offset into the leaf dirent space. Hence:
> 
> 	leaf[].address = bu[16].tag >> 3
> 			= 0x1d8 >> 3
> 			= 0x3b
> 			= bleaf[3].address
> 
>> bleaf[3].hashval = 0x16d0707c
>> bleaf[3].address = 0x3b
> 
> And there were are - there's a single bit discrepancy in the lower
> byte of the hash. That tends to imply we have a bug in xfs_repair.
> 
> What version of xfs_repair did you use? (xfs_repair -V)


3.1.11.

I’m happy to build from git if you suspect something has changed since then.

	Zach


[-- Attachment #1.2: smime.p7s --]
[-- Type: application/pkcs7-signature, Size: 2749 bytes --]

[-- Attachment #2: Type: text/plain, Size: 121 bytes --]

_______________________________________________
xfs mailing list
xfs@oss.sgi.com
http://oss.sgi.com/mailman/listinfo/xfs

Re: Files with non-ASCII names inaccessible after xfs_repair

[Dave Chinner]

On Tue, Jan 14, 2014 at 05:59:23PM -0800, Zachary Kotlarek wrote:
> 
> On Jan 14, 2014, at 5:53 PM, Dave Chinner <david@fromorbit.com> wrote:
> 
> > Pretty simple - the leaf[].address is simply a compressed offset
> > into the leaf. all dirents are 8 byte aligned, and the tag is the
> > byte offset into the leaf dirent space. Hence:
> > 
> > 	leaf[].address = bu[16].tag >> 3
> > 			= 0x1d8 >> 3
> > 			= 0x3b
> > 			= bleaf[3].address
> > 
> >> bleaf[3].hashval = 0x16d0707c
> >> bleaf[3].address = 0x3b
> > 
> > And there were are - there's a single bit discrepancy in the lower
> > byte of the hash. That tends to imply we have a bug in xfs_repair.
> > 
> > What version of xfs_repair did you use? (xfs_repair -V)
> 
> 
> 3.1.11.

OK, Now I've looked at the code, the answer is easy and you're
probably not going to like it. I missed this the first time through
from your xfs-info output:

naming   =version 2              bsize=4096   ascii-ci=1
                                              ^^^^^^^^^^

It's called *ASCII* Case Insensitivity for a reason: it doesn't
support anything other than ASCII. So your usage is not actually
supported at all, hence it's no surprise that it has caused
breakage.

Internationalised UTF-8 character sets are not supported
because it causes case conversion issues when kernel and userspace
character sets don't match exactly. IOWs, to support UTF-8 case
insensitivity, we need to have on-disk translation tables so that
the kernel and userspace use the same case translations. See here:

http://xfs.org/index.php/Unfinished_work#Support_for_unicode_.2F_utf8_filesystems

I suspect that the way to fix your filesystem is to run xfs_repair
under a "C" locale so that the glibc tolower() function behaves the
same way the kernel behaves and so the hashes calculated by
xfs_repair match the what the kernel thinks is correct.

Cheers,

Dave.
-- 
Dave Chinner
david@fromorbit.com

_______________________________________________
xfs mailing list
xfs@oss.sgi.com
http://oss.sgi.com/mailman/listinfo/xfs

Re: Files with non-ASCII names inaccessible after xfs_repair

[Zachary Kotlarek]

[-- Attachment #1.1: Type: text/plain, Size: 1301 bytes --]


On Jan 14, 2014, at 7:48 PM, Dave Chinner <david@fromorbit.com> wrote:

> It's called *ASCII* Case Insensitivity for a reason: it doesn't
> support anything other than ASCII. So your usage is not actually
> supported at all, hence it's no surprise that it has caused
> breakage.


Okay. Thanks for the explanation.

FWIW, I read “ASCII-only case-insensitive” to mean “only case-insensitive for ASCII” as in ñ and Ñ would not match each other. If it actually means “anything other than ASCII is subject to complete breakage” a more nuanced explanation in the man page might be desirable.

I don’t suppose there’s any way to disable that setting short of creating a new file system?


> I suspect that the way to fix your filesystem is to run xfs_repair
> under a "C" locale so that the glibc tolower() function behaves the
> same way the kernel behaves and so the hashes calculated by
> xfs_repair match the what the kernel thinks is correct.

Neither this:
	LC_ALL=C
nor this:
	LC_ALL=POSIX
or for that matter:
	LC_ALL=en_US.utf8
made any difference. And my default was already POSIX.

Any other thoughts?

Theoretically I could find the expected hashvals and overwrite them with xfs_db, right? Or at least unlink the files so I can reclaim the disk space?

	Zach


[-- Attachment #1.2: smime.p7s --]
[-- Type: application/pkcs7-signature, Size: 2749 bytes --]

[-- Attachment #2: Type: text/plain, Size: 121 bytes --]

_______________________________________________
xfs mailing list
xfs@oss.sgi.com
http://oss.sgi.com/mailman/listinfo/xfs

Re: Files with non-ASCII names inaccessible after xfs_repair

[Dave Chinner]

On Tue, Jan 14, 2014 at 09:30:57PM -0800, Zachary Kotlarek wrote:
> 
> On Jan 14, 2014, at 7:48 PM, Dave Chinner <david@fromorbit.com> wrote:
> 
> > It's called *ASCII* Case Insensitivity for a reason: it doesn't
> > support anything other than ASCII. So your usage is not actually
> > supported at all, hence it's no surprise that it has caused
> > breakage.
> 
> Okay. Thanks for the explanation.
> 
> FWIW, I read “ASCII-only case-insensitive” to mean “only case-insensitive for ASCII” as in ñ and Ñ would not match each other. If it actually means “anything other than ASCII is subject to complete breakage” a more nuanced explanation in the man page might be desirable.

Sure. Can you write a patch to add explanation that explain the
problem you've had?

> I don’t suppose there’s any way to disable that setting short of creating a new file system?

Not officially. Changing it means you have to change every single
hash for every directory entry. I *think* that you could probably do
it with a bit of xfs_db magic and and xfs_repair pass.

First, A warning, some advice and a disclaimer: back up anything you
don't want to lose, because if this screws up it'll trash the
directory structure and you may *LOSE* *ALL* *YOUR* *DATA*. This is
dangerous, not recommended and I take no responsibility for what
happens if you try it and it fails.

After taking a backup, use xfs_metadump to set up for a
non-destructive trial run.  take a copy of the filesystem metadata
using xfs_metadump:

# xfs_metadump <dev> scratch.metadump

Restore the metadump to a file - this is a sparse image file we can
operate on safely.

# xfs_mdrestore scratch.metadump scratch_xfs_filesystem.img

Then point xfs_db at the image file:

# xfs_db -x -f scratch_xfs_filesystem.img

Remove the case insensitive feature bit using the version command.
First dump the current values using version:

xfs_db> version
versionnum [0xf4a4+0x8a] = V4,NLINK,ALIGN,DIRV2,LOGV2,EXTFLG,ASCII_CI,MOREBITS,ATTR2,LAZYSBCOUNT,PROJID32BIT

And you'll see the ASCII_CI bit in there. That's what we want to
remove. It's value is:

#define XFS_SB_VERSION_BORGBIT          0x4000

so we need to clear that from the version field.

	0xf4a4 - 0x4000 = 0xb4a4

And we want to write that back into the version field:

xfs_db> sb 0
xfs_db> p versionnum
versionnum = 0xf4a4
xfs_db> write versionnum 0xb4a4
versionnum = 0xb4a4
xfs_db> p versionnum
versionnum = 0xb4a4
xfs_db> quit

And now run xfs_repair on the image file:

# xfs_repair -f scratch_xfs_filesystem.img

That should through lots of "bad hash table.... repairing" errors.
Once it completes, mount the filesystem image on the loopback
device:

# mount -o loop,ro,norecovery scratch_xfs_filesystem.img /mnt/scratch

And walk around the filesystem to determine if the directory
structure is correct and intact. If you have any doubts, or anything
was left in lost+found, then it hasn't worked properly and you
should not do this to your filesystem.

Only if you are convinced that everything is OK and you can do the
conversion without stuffing up, run the same xfs_db/repair process
on the real filesystem. If you have any doubts or not confident that
it has worked, then go the long way of mkfs and restoring the backup
you've already made.

> > I suspect that the way to fix your filesystem is to run xfs_repair
> > under a "C" locale so that the glibc tolower() function behaves the
> > same way the kernel behaves and so the hashes calculated by
> > xfs_repair match the what the kernel thinks is correct.
> 
> Neither this:
> 	LC_ALL=C
> nor this:
> 	LC_ALL=POSIX
> or for that matter:
> 	LC_ALL=en_US.utf8
> made any difference. And my default was already POSIX.
> 
> Any other thoughts?

$ LC_ALL=C locale
LANG=en_AU.UTF-8
LANGUAGE=en_AU:en
LC_CTYPE="C"
LC_NUMERIC="C"
LC_TIME="C"
LC_COLLATE="C"
LC_MONETARY="C"
LC_MESSAGES="C"
LC_PAPER="C"
LC_NAME="C"
LC_ADDRESS="C"
LC_TELEPHONE="C"
LC_MEASUREMENT="C"
LC_IDENTIFICATION="C"
LC_ALL=C
$

Perhaps you also need to override LANG and LANGUAGE?

> Theoretically I could find the expected hashvals and overwrite
> them with xfs_db, right?

In theory, but hashvals need to be ordered correctly and that
potentially means having to update btree node pointers and all sorts
of other complexities. xfs_db is really not designed to rewrite
directory structures manually.

> Or at least unlink the files so I can
> reclaim the disk space?

You need to be able to stat the file to be able to unlink it....

Cheers,

Dave.
-- 
Dave Chinner
david@fromorbit.com

_______________________________________________
xfs mailing list
xfs@oss.sgi.com
http://oss.sgi.com/mailman/listinfo/xfs

Re: Files with non-ASCII names inaccessible after xfs_repair

[Zachary Kotlarek]

[-- Attachment #1.1: Type: text/plain, Size: 1064 bytes --]


On Jan 14, 2014, at 10:37 PM, Dave Chinner <david@fromorbit.com> wrote:

> Sure. Can you write a patch to add explanation that explain the
> problem you've had?


Will do.


>> Theoretically I could find the expected hashvals and overwrite
>> them with xfs_db, right?
> 
> In theory, but hashvals need to be ordered correctly and that
> potentially means having to update btree node pointers and all sorts
> of other complexities. xfs_db is really not designed to rewrite
> directory structures manually.


It occurs to me the other way around is probably easier anyway — change the name entry to something ASCII-only (of the same byte length) and let xfs_repair rebuild the hash. That’s what got me into this mess, so by cartoon logic it should fix things if I do it again. ;-)

After testing that theory on a metadata dump I spun up an LVM snapshot, where it also seems to work. So that gets me back into a functional state, but given all the mucking I think I’ll restore a clean FS again anyway.

Thanks again for your help.

	Zach


[-- Attachment #1.2: smime.p7s --]
[-- Type: application/pkcs7-signature, Size: 2749 bytes --]

[-- Attachment #2: Type: text/plain, Size: 121 bytes --]

_______________________________________________
xfs mailing list
xfs@oss.sgi.com
http://oss.sgi.com/mailman/listinfo/xfs

Re: Files with non-ASCII names inaccessible after xfs_repair

[Eric Sandeen]

On 1/15/14, 12:37 AM, Dave Chinner wrote:
> On Tue, Jan 14, 2014 at 09:30:57PM -0800, Zachary Kotlarek wrote:
>>
>> On Jan 14, 2014, at 7:48 PM, Dave Chinner <david@fromorbit.com> wrote:
>>
>>> It's called *ASCII* Case Insensitivity for a reason: it doesn't
>>> support anything other than ASCII. So your usage is not actually
>>> supported at all, hence it's no surprise that it has caused
>>> breakage.
>>
>> Okay. Thanks for the explanation.
>>
>> FWIW, I read “ASCII-only case-insensitive” to mean “only case-insensitive for ASCII” as in ñ and Ñ would not match each other. If it actually means “anything other than ASCII is subject to complete breakage” a more nuanced explanation in the man page might be desirable.
> 
> Sure. Can you write a patch to add explanation that explain the
> problem you've had?
> 
>> I don’t suppose there’s any way to disable that setting short of creating a new file system?
> 
> Not officially. Changing it means you have to change every single
> hash for every directory entry. I *think* that you could probably do
> it with a bit of xfs_db magic and and xfs_repair pass.
> 
> First, A warning, some advice and a disclaimer: back up anything you
> don't want to lose, because if this screws up it'll trash the
> directory structure and you may *LOSE* *ALL* *YOUR* *DATA*. This is
> dangerous, not recommended and I take no responsibility for what
> happens if you try it and it fails.
> 
> After taking a backup, use xfs_metadump to set up for a
> non-destructive trial run.  take a copy of the filesystem metadata
> using xfs_metadump:
> 
> # xfs_metadump <dev> scratch.metadump

NB: You'll want to add the "-o" option to not obfuscate filenames, or
you'll probably have no idea if Dave's later steps are working or not.


(I haven't read the whole thread, but is there no way for ascii-ci mode
to reject non-ascii names in the first place?  This seems like quite
the pitfall.)

-Eric

_______________________________________________
xfs mailing list
xfs@oss.sgi.com
http://oss.sgi.com/mailman/listinfo/xfs

Re: Files with non-ASCII names inaccessible after xfs_repair

[Dave Chinner]

On Wed, Jan 15, 2014 at 09:54:02AM -0600, Eric Sandeen wrote:
> On 1/15/14, 12:37 AM, Dave Chinner wrote:
> > On Tue, Jan 14, 2014 at 09:30:57PM -0800, Zachary Kotlarek wrote:
> >>
> >> On Jan 14, 2014, at 7:48 PM, Dave Chinner <david@fromorbit.com> wrote:
> >>
> >>> It's called *ASCII* Case Insensitivity for a reason: it doesn't
> >>> support anything other than ASCII. So your usage is not actually
> >>> supported at all, hence it's no surprise that it has caused
> >>> breakage.
> >>
> >> Okay. Thanks for the explanation.
> >>
> >> FWIW, I read “ASCII-only case-insensitive” to mean “only case-insensitive for ASCII” as in ñ and Ñ would not match each other. If it actually means “anything other than ASCII is subject to complete breakage” a more nuanced explanation in the man page might be desirable.
> > 
> > Sure. Can you write a patch to add explanation that explain the
> > problem you've had?
> > 
> >> I don’t suppose there’s any way to disable that setting short of creating a new file system?
> > 
> > Not officially. Changing it means you have to change every single
> > hash for every directory entry. I *think* that you could probably do
> > it with a bit of xfs_db magic and and xfs_repair pass.
> > 
> > First, A warning, some advice and a disclaimer: back up anything you
> > don't want to lose, because if this screws up it'll trash the
> > directory structure and you may *LOSE* *ALL* *YOUR* *DATA*. This is
> > dangerous, not recommended and I take no responsibility for what
> > happens if you try it and it fails.
> > 
> > After taking a backup, use xfs_metadump to set up for a
> > non-destructive trial run.  take a copy of the filesystem metadata
> > using xfs_metadump:
> > 
> > # xfs_metadump <dev> scratch.metadump
> 
> NB: You'll want to add the "-o" option to not obfuscate filenames, or
> you'll probably have no idea if Dave's later steps are working or not.
> 
> 
> (I haven't read the whole thread, but is there no way for ascii-ci mode
> to reject non-ascii names in the first place?  This seems like quite
> the pitfall.)

The utf-8 patches add a "is this valid utf-8" check to all the
operations that care. We could probably do that for the ASCII-CI
stuff if you can define what ASCII means....

Cheers,

Dave.
-- 
Dave Chinner
david@fromorbit.com

_______________________________________________
xfs mailing list
xfs@oss.sgi.com
http://oss.sgi.com/mailman/listinfo/xfs

Re: Files with non-ASCII names inaccessible after xfs_repair

[Michael Weissenbacher]

Hi!
>
> The utf-8 patches add a "is this valid utf-8" check to all the
> operations that care. We could probably do that for the ASCII-CI
> stuff if you can define what ASCII means....
>
That's easy actually, since ASCII is a 7-bit code it can only contain 
char values between 0-127 or in other words the highest bit must not be 
set in any char. But probably this strict check could break other stuff.

cheers,
Michael

_______________________________________________
xfs mailing list
xfs@oss.sgi.com
http://oss.sgi.com/mailman/listinfo/xfs

RE: Files with non-ASCII names inaccessible after xfs_repair

[Shaun Gosse]

> That's easy actually, since ASCII is a 7-bit code it can only contain char values between 0-127 or in other words the highest bit must not be set in any char. But probably this strict check could break other stuff.

As long as you exclude extended ascii and data corruption, I don't know what else that could break. My guess would be that ASCII as understood by XFS users would be the 0-127 and not the various mix of extensions. If you want to include support for extended ascii...then I don't think there's any way to determine non-probabilistically the difference between ASCII and UTF based on the data itself.

I have no idea what the current behavior is with respect to extended ASCII (whether it's supported, or works, or anything).

Cheers,
-Shaun

-----Original Message-----
From: xfs-bounces@oss.sgi.com [mailto:xfs-bounces@oss.sgi.com] On Behalf Of Michael Weissenbacher
Sent: Thursday, January 16, 2014 2:56 PM
To: xfs@oss.sgi.com
Subject: Re: Files with non-ASCII names inaccessible after xfs_repair

Hi!
>
> The utf-8 patches add a "is this valid utf-8" check to all the 
> operations that care. We could probably do that for the ASCII-CI stuff 
> if you can define what ASCII means....
>
That's easy actually, since ASCII is a 7-bit code it can only contain char values between 0-127 or in other words the highest bit must not be set in any char. But probably this strict check could break other stuff.

cheers,
Michael

_______________________________________________
xfs mailing list
xfs@oss.sgi.com
http://oss.sgi.com/mailman/listinfo/xfs

_______________________________________________
xfs mailing list
xfs@oss.sgi.com
http://oss.sgi.com/mailman/listinfo/xfs

Re: Files with non-ASCII names inaccessible after xfs_repair

[Michael Weissenbacher]

Hi Zach!
> I now have 23 directories (matching the 23 “rebuilding" messages) where a file or directory with non-ASCII characters in the name exists in the directory list but cannot be read or deleted:
>
> ls -la
> ls: cannot access 07 - Señor Macho Solo.m4v: No such file or directory
> -rw-rw----+  1 profplump media 332M Sep 11  2010 06 - Christmas Special.m4v
> ???????????  ? ?         ?        ?            ? 07 - Se??or Macho Solo.m4v
> -rw-rw----+  1 profplump media 304M Sep 11  2010 08 - Flu Shot.m4v
>
Might be a long shot, but have you tried mounting the file system with 
"-o inode64"?

cheers,
Michael

---
This email is free from viruses and malware because avast! Antivirus protection is active.
http://www.avast.com

_______________________________________________
xfs mailing list
xfs@oss.sgi.com
http://oss.sgi.com/mailman/listinfo/xfs

Re: Files with non-ASCII names inaccessible after xfs_repair

[Zachary Kotlarek]

[-- Attachment #1.1: Type: text/plain, Size: 894 bytes --]


On Jan 13, 2014, at 7:40 AM, Michael Weissenbacher <mw@dermichi.com> wrote:

> Hi Zach!
>> I now have 23 directories (matching the 23 “rebuilding" messages) where a file or directory with non-ASCII characters in the name exists in the directory list but cannot be read or deleted:
>> 
>> ls -la
>> ls: cannot access 07 - Señor Macho Solo.m4v: No such file or directory
>> -rw-rw----+  1 profplump media 332M Sep 11  2010 06 - Christmas Special.m4v
>> ???????????  ? ?         ?        ?            ? 07 - Se??or Macho Solo.m4v
>> -rw-rw----+  1 profplump media 304M Sep 11  2010 08 - Flu Shot.m4v
>> 
> Might be a long shot, but have you tried mounting the file system with "-o inode64"?


Thanks for the though. That’s already my default:

/dev/lvmsas/tv /mnt/media/TV xfs rw,nosuid,nodev,noexec,relatime,attr2,delaylog,inode64,sunit=1024,swidth=4096,noquota 0 0

	Zach


[-- Attachment #1.2: smime.p7s --]
[-- Type: application/pkcs7-signature, Size: 2749 bytes --]

[-- Attachment #2: Type: text/plain, Size: 121 bytes --]

_______________________________________________
xfs mailing list
xfs@oss.sgi.com
http://oss.sgi.com/mailman/listinfo/xfs