On 3/2/2019 3:42 PM, Ciprian Dorin Craciun wrote: > On Wed, Dec 5, 2018 at 3:29 PM Harald Barth <[email protected]> wrote: >>> Can I safely `rsync` the files from the old partition to the new one? >> >> For Linux (The "new" server partition layout): >> >> If the file tree really is exactly copied (including all permissions >> and chmod-bits) then you have everything you need. > > > > I would like to follow-up on this with some additional questions, > which I'll try to keep as succinct as possible. (Nothing critical, > however I would like to have a little bit more insight into this.) > > (A) When you state `exactly copied` you mean only the following > (based on the `struct stat` members): > * `st_uid` / `st_gid`; > * `st_mode`; (i.e. permissions;) > * `st_atim`, `st_mtim` and `st_ctim`? (i.e. timestamps) > * no ACL's, no `xattr` (or `user_xattr`); > * anything else?
The vice partition directory hierarchy is used to create a private object store. The reason that Harald said "exact copy" is because OpenAFS leverages the fact that the "dafs" or "fs" bnode services execute as "root" to encode information in the inode's metadata that is not guaranteed to be a valid state from the perspective of normal file tooling. The current Linux OpenAFS vice partition format is endian sensitive. For many years there was discussion of creating a plug-in interface for the vice partition object storage. This would permit separate formats depending on the underlying file system capabilities and use of non-file system object stores. > (B) Also (based on what I gathered by "peeking" into the `/vicepX` > partition) there are only plain folders and plain files, without any > symlinks or hard-links. This is true for the current OpenAFS vice partition format. It is not true for all vice partition formats used by non-OpenAFS implementations. > (C) Moreover based on the same observations, I guess that the > metadata (i.e. uid/gid/permissions/timestamps) for the actual folders > inside of `/vicepX` don't matter much. (Only the matadata for the > actual files do.) This is true for the existing OpenAFS vice partition format on Linux. > (D) (Not really related to migration) Am I to assume that some of > the files inside `AFSIDat` are identical in contents to the actual > files on the `/afs` structure? (Disregarding all meta-data, including > filenames.) Moreover am I to assume that all the files accessible > from `/afs` are found somewhere inside `AFSIDat` with identical > contents? There is a mapping from AFS3 File ID to vice partition path. AFS3 directories are stored as files as are AFS3 files, symlinks and mount points. OpenAFS stores each AFS3 File ID data stream in a single file in the current format. > I.e. formalizing the last one: if one would take any file accessible > under `/afs` and would compute its SHA1, then by looking into all > `/vicepX` partitions belonging to that cell, one would definitively > find a matching file with that SHA1. This is true for the current format. > My curiosity into all this is because I want to prepare some `rsync` > and `cpio` snippets that perhaps could help others in a similar > endeavor. Moreover (although I know there are at least two other > "official" ways to achieve this) it can serve as an alternative backup > mechanism. The vice partition format should be considered to be private to the fileserver processes. It is not portable and should not be used as a backup or transfer mechanism. > BTW, is there a document that outlines the actual layout of the > `/vicepX` structure? I've searched a bit but found nothing useful. The source code comments provide the best documentation. Jeffrey Altman
smime.p7s
Description: S/MIME Cryptographic Signature
