| To: | Samuel Just <sam.just@xxxxxxxxxxx> |
|---|---|
| Subject: | Re: consequences of XFS_IOC_FSSETXATTR on non-empty file? |
| From: | Dave Chinner <david@xxxxxxxxxxxxx> |
| Date: | Sun, 13 Jul 2014 11:26:24 +1000 |
| Cc: | xfs@xxxxxxxxxxx, "ceph-devel@xxxxxxxxxxxxxxx" <ceph-devel@xxxxxxxxxxxxxxx>, Sage Weil <sage@xxxxxxxxxxx>, Ilya Dryomov <ilya.dryomov@xxxxxxxxxxx> |
| Delivered-to: | xfs@xxxxxxxxxxx |
| In-reply-to: | <CA+4uBUYg+81G2=sj3qXO4GGgA7pyjgVrGDCN+UQ32jnWgSbG5w@xxxxxxxxxxxxxx> |
| References: | <CA+4uBUYg+81G2=sj3qXO4GGgA7pyjgVrGDCN+UQ32jnWgSbG5w@xxxxxxxxxxxxxx> |
| User-agent: | Mutt/1.5.21 (2010-09-15) |
On Sat, Jul 12, 2014 at 06:16:54PM -0700, Samuel Just wrote: > Hi, > > We are seeing reports of ceph-osd stores on xfs of files with some > garbage data (possibly misplaced from data elsewhere in the > filesystem). There was a bug for a while where the ceph-osd process > would set a value for fsx_extsize on a non-empty (possibly sparse) > file using XFS_IOC_FSSETXATTR. Could that plausibly result in a file > with garbage data? No, setting an extent size on a non-empty file will simply fail with EINVAL. Do you have any method of reproducing the bad data in files? Cheers, Dave. -- Dave Chinner david@xxxxxxxxxxxxx |
| <Prev in Thread] | Current Thread | [Next in Thread> |
|---|---|---|
| ||
| Previous by Date: | consequences of XFS_IOC_FSSETXATTR on non-empty file?, Samuel Just |
|---|---|
| Next by Date: | Re: consequences of XFS_IOC_FSSETXATTR on non-empty file?, Samuel Just |
| Previous by Thread: | consequences of XFS_IOC_FSSETXATTR on non-empty file?, Samuel Just |
| Next by Thread: | Re: consequences of XFS_IOC_FSSETXATTR on non-empty file?, Samuel Just |
| Indexes: | [Date] [Thread] [Top] [All Lists] |