Hugo Mills <hugo@xxxxxxxxxxxxx> wrote: > > (1) 64-bit data version numbers that increase monotonically with > > each write. Yes, this is likely to cause some performance > > degredation as it introduces an ordering over data writes and > > metadata writes to a file. Maybe writes can be batched to improve > > performance? > > Do these have to be per-file? If not, then you might be able to get > away with using the transid, which is a filesystem-global > monotonically-increasing number. Yes. If you send a write RPC op to the server, you get back the new version number. If the new version number is not the old version number + 1 you know there was a collision with a write from another client and you have to flush your cache for that file and request a new "callback" (ie. a promise to notify you if someone else changes the file). > > (3) The ability to snapshot a filesystem to make backups and for > > pushing to read-only volume servers. > > We have snapshots of subvolumes, but not the filesystem as a whole. By "filesystem" I meant the current state of an AFS volume. Very likely this would be represented by a BTRFS subvolume, if I understand it correctly. You might have several AFS volumes represented within a BTRFS filesystem. They would be manipulated independently. > > (5) The ability to set the vnode number, vnode uniquifier and data > > version number to specific values. Necessary to clone volumes > > and restore volume dumps. > > What's a vnode meant to represent? I'm not familiar with the > terminology. AFS's equivalent of an inode with a 32-bit number representing it. See my reply to Chris's question about the same thing. David -- To unsubscribe from this list: send the line "unsubscribe linux-btrfs" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
