RE: Problems with cephfs, rsync and xattr because cephfs internal xattrs are exposed to clients.

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



I doubt that rsync is the only application that's going to be confused by the presence of attributes it doesn't understand.

What is the value in having these attributes be visible to user-space applications? Is there a better mechanism for conveying this information?

There's nothing to prevent having a debug-ish toggle to expose them when you really want to see them.

Allen Samuels
SanDisk |a Western Digital brand
2880 Junction Avenue, San Jose, CA 95134
T: +1 408 801 7030| M: +1 408 780 6416
allen.samuels@xxxxxxxxxxx


> -----Original Message-----
> From: ceph-devel-owner@xxxxxxxxxxxxxxx [mailto:ceph-devel-
> owner@xxxxxxxxxxxxxxx] On Behalf Of Sage Weil
> Sent: Tuesday, June 21, 2016 2:30 PM
> To: Michael Wyraz <michael@xxxxxxxx>
> Cc: ceph-devel@xxxxxxxxxxxxxxx
> Subject: Re: Problems with cephfs, rsync and xattr because cephfs internal
> xattrs are exposed to clients.
> 
> On Tue, 21 Jun 2016, Michael Wyraz wrote:
> > Hi,
> >
> > I do rsync based backups against a cephfs. If I do sync xattrs, rsync
> > tries to delete ceph-internal xattrs (e.g. ceph.dir.entries) which fails with an
> error.
> > xattrs does not get synchronized in this case.
> > IMO the problem is, that ceph's internal attributes are exposed to the
> > mounted fileystem (I can do "getfattr -n ceph.dir.entries *" on the
> > mounted cephfs and get results). So rsync sees these xattrs and tries to
> remove it.
> >
> > Example output:
> >
> >    rsync: rsync_xal_set:
> >    lremovexattr(""/backups/2016-05-31_00-09-
> 32/etc/acpi/events"","ceph.dir.entries")
> >    failed: Operation not supported (95)
> >    rsync: rsync_xal_set:
> >    lremovexattr(""/backups/2016-05-31_00-09-
> 32/etc/acpi/events"","ceph.dir.files")
> >    failed: Operation not supported (95)
> >    rsync: rsync_xal_set:
> >    lremovexattr(""/backups/2016-05-31_00-09-
> 32/etc/acpi/events"","ceph.dir.subdirs")
> >    failed: Operation not supported (95)
> >    rsync: rsync_xal_set:
> >    lremovexattr(""/backups/2016-05-31_00-09-
> 32/etc/acpi/events"","ceph.dir.rentries")
> >    failed: Operation not supported (95)
> >    rsync: rsync_xal_set:
> >    lremovexattr(""/backups/2016-05-31_00-09-
> 32/etc/acpi/events"","ceph.dir.rfiles")
> >    failed: Operation not supported (95)
> >    rsync: rsync_xal_set:
> >    lremovexattr(""/backups/2016-05-31_00-09-
> 32/etc/acpi/events"","ceph.dir.rsubdirs")
> >    failed: Operation not supported (95)
> >    rsync: rsync_xal_set:
> >    lremovexattr(""/backups/2016-05-31_00-09-
> 32/etc/acpi/events"","ceph.dir.rbytes")
> >    failed: Operation not supported (95)
> >    rsync: rsync_xal_set:
> >    lremovexattr(""/backups/2016-05-31_00-09-
> 32/etc/acpi/events"","ceph.dir.rctime")
> >    failed: Operation not supported (95)
> 
> I think the right fix here is to patch rsync to ignore ceph.* xattrs.
> Does that seem reasonable?
> 
> Other possible workarounds might be:
> 
>  - ignore setxattr and removexattr requests on these xattrs (return success
> but do nothing)
>  - never show these xattrs in listxattr.  this makes them less useful or friendly
> :(
> 
> sage
> --
> To unsubscribe from this list: send the line "unsubscribe ceph-devel" in the
> body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at
> http://vger.kernel.org/majordomo-info.html
--
To unsubscribe from this list: send the line "unsubscribe ceph-devel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html



[Index of Archives]     [CEPH Users]     [Ceph Large]     [Information on CEPH]     [Linux BTRFS]     [Linux USB Devel]     [Video for Linux]     [Linux Audio Users]     [Yosemite News]     [Linux Kernel]     [Linux SCSI]

  Powered by Linux