[Top] [All Lists]

Re: Files with non-ASCII names inaccessible after xfs_repair

To: xfs@xxxxxxxxxxx
Subject: Re: Files with non-ASCII names inaccessible after xfs_repair
From: Zachary Kotlarek <zach@xxxxxxxxxxxx>
Date: Sun, 12 Jan 2014 18:36:03 -0800
Delivered-to: xfs@xxxxxxxxxxx
Dkim-signature: v=1; a=rsa-sha256; c=simple/simple; d=kotlarek.com; s=default; t=1389580566; bh=jC5woj8nMkTE+uMw5xmYgtOyVeng7s26bYcgosITED0=; h=From:Content-Type:Message-Id:Mime-Version:Subject:Date:References: To:In-Reply-To; b=FBhFPXlI/mitw1RUhtzg8vb0hvhGUJz7NydtvgsJBWgQxVtM4sj/zGYUwStYeCTIK PDzQrxqESsHEus0pbC+pDkaTxFza/qktLjMiW7px7/bfusxvoD2Y5GIQONTAglhD08 VVAR7scIKNC/QWTCiVcthbYuAUf7Dc4y4jmob9uQ=
In-reply-to: <20140113015007.GC3469@dastard>
References: <A40DF90D-5F6B-4595-AA30-B91D8F7972D0@xxxxxxxxxxxx> <52D2E358.6070106@xxxxxxxxxxxxxxxxx> <CF41F386-E86A-4745-B28D-0DAA8D3CA1DD@xxxxxxxxxxxx> <20140113015007.GC3469@dastard>
On Jan 12, 2014, at 5:50 PM, Dave Chinner <david@xxxxxxxxxxxxx> 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
> 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.


Attachment: smime.p7s
Description: S/MIME cryptographic signature

<Prev in Thread] Current Thread [Next in Thread>