From: Nikolaus R. <Nik...@ra...> - 2014-06-07 01:50:14
|
[Quoting repaired] Shachar Sharon <syn...@pu...> writes: > On Fri, Jun 6, 2014 at 3:44 AM, Nikolaus Rath <Nik...@ra...> wrote: >> Shachar Sharon <syn...@pu...> writes: >>> Hi all, >>> I want to implement file-cloning for FUSE based file system (use-case: >>> multiple vms which share single golden-image). >>> >>> Unfortunately, btrfs' ioctl solution, used by coreutils to implement 'cp >>> --reflink...', will not work properly for FUSE >>> ( >>> http://git.savannah.gnu.org/gitweb/?p=coreutils.git;a=commitdiff;h=45330176690b079ed47ac7c58f29a1b028f97b07 >>> ) >>> >>> Did anyone implement such functionality for FUSE based file-system, via >>> ioctl or in any other way? What arguments did he pass over to the >>> server? >> >> I implemented it with extended attributes. Cloning is achieved by >> setting two special extended attributes on a hidden file at the root of >> the mountpoint to the inode of the source and destination. That means >> you can't use cp --reflink though, I'm providing a separate command >> (that could fall back to cp --reflink when used on a different file >> system). >> > Hi Nikolaus, > Thank you for your reply. > Could you please specify the key/value arguments you use in your > solution? I am asking for those details because I do not want to > compromise security in favor of usability. I use an extended attribute called "copy", and its value is a serialized Python tuple consisting of the source and target inode numbers (cf. https://bitbucket.org/nikratio/s3ql/src/72db316185ff42af517998ff11dd4fc349e730b4/src/s3ql/cp.py?at=default#cl-90) I do not understand your point about security vs usability though. Best, Nikolaus -- GPG encrypted emails preferred. Key id: 0xD113FCAC3C4E599F Fingerprint: ED31 791B 2C5C 1613 AF38 8B8A D113 FCAC 3C4E 599F »Time flies like an arrow, fruit flies like a Banana.« |