On Sun, Jul 13, 2014 at 5:48 AM, Samuel Just <[email protected]> wrote:
> Actually, on this ubuntu kernel (3.13.0-24-generic), it doesn't seem
> to give an error. I'll attach my test case for that. We don't yet
> have a way of reproducing the corruption -- the ext_size change in the
> osd simply seemed like a promising lead.
> -Sam
>
> On Sat, Jul 12, 2014 at 6:26 PM, Dave Chinner <[email protected]> wrote:
>> 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.
AFAIR it checks whether or not any extents are actually allocated, not
whether the file is empty or not. I think if you call fsync() or even
fdatasync() before close(fd), it will fail as expected.
Thanks,
Ilya
--
To unsubscribe from this list: send the line "unsubscribe ceph-devel" in
the body of a message to [email protected]
More majordomo info at http://vger.kernel.org/majordomo-info.html
