Date: Mon, 7 Mar 2016 21:26:42 -0800 From: Jordan Hubbard <jkh@ixsystems.com> To: Robert Watson <rwatson@FreeBSD.org> Cc: Julian Elischer <julian@FreeBSD.ORG>, Ken Merry <ken@freebsd.org>, fs@freebsd.org, scsi@freebsd.org Subject: Re: FUSE extended attribute patches available Message-ID: <536B3B67-E8F6-472C-8A2C-8884533B4CB6@ixsystems.com> In-Reply-To: <6AF0FC23-CC34-43EA-A008-9FB82FB21558@FreeBSD.org> References: <CD5FCB90-1952-4014-BBE0-1BFF1EF85E17@freebsd.org> <800018199.6694281.1457233600357.JavaMail.zimbra@uoguelph.ca> <56DD2AB6.1030407@freebsd.org> <6AF0FC23-CC34-43EA-A008-9FB82FB21558@FreeBSD.org>
next in thread | previous in thread | raw e-mail | index | archive | help
> On Mar 6, 2016, at 11:59 PM, Robert Watson <rwatson@FreeBSD.org> = wrote: >=20 > For example: who should be responsible for backing up those = attributes? For =E2=80=98system=E2=80=99 attributes in FreeBSD, it is = assumed that backup tools will be aware of the services layered over the = attributes =E2=80=94 e.g., that they will back up ACLs using the ACL = API, rather than backing up the binary EAs holding the ACLs. For = =E2=80=98user=E2=80=99 attributes, it is assumed that backup tools = (e.g., tar) must explicitly preserve them, since they are user-defined = and user-managed. For filesystem-specific attributes, some other choice = will need to be made =E2=80=94 perhaps filesystem-specific backup tools = need to know about them? As Rick observed, the last time this came up, I pointed out that = teaching all possible =E2=80=9Carchivers=E2=80=9D of filesystem = information (which includes serializers, like rsync / scp / etc) how to = cope gracefully with EAs and ACLs, even if you stick ACLs in an EA = system namespace and make them opaque blobs, is =E2=80=9Chard=E2=80=9D = and it=E2=80=99s the edge/legacy cases that really hose you. This is why Apple chose to split the problem space between =E2=80=9Cthings= that are capable of dealing with the problem natively=E2=80=9D = (abstracting that native understanding behind the copyfile(3) APIs), = which is a comparatively small number of tools, and =E2=80=9Ceverything = else=E2=80=9D which gets all of its metadata serialized into an = AppleDouble file. Yes, those are the ._* files you see when you copy a = bunch of files off your Mac onto a filesystem that doesn=E2=80=99t know = how to cope with the metadata. The extra AppleDouble files just sit = around passively on that NTFS or ext2fs filesystem, minding their own = business, until they get copied back to to Mac, at which point something = at the VFS layer (I=E2=80=99m guessing now, I never actually looked) = re-unites the ._Foo file with its corresponding Foo file and the = AppleDouble file disappears. I used to think this was kind of ghetto, then I observed how many = problems it solved in terms of turning data-loss scenarios into =E2=80=9Cn= o big deal, it=E2=80=99ll all work out=E2=80=9D scenarios and I changed = my mind. TL;DR summary: This can be handled in such a way that =E2=80=9Cno one = need be responsible=E2=80=9D for backing up those attributes if you=E2=80=99= re willing to pay the freight. - Jordan
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?536B3B67-E8F6-472C-8A2C-8884533B4CB6>