I'm not sure who to ask about this, but I'm curious whether the new ZFS_REPARSEPOINT might be redundant with the existing flag (in the "dos attributes field") XAT_REPARSE. See: http://src.illumos.org/source/search?project=illumos-gate&refs=XAT_REPARSE The illumos in-kernel SMB server uses links with that attribute set to represent reparse points to SMB and NFS clients.
Note there are also "dos attributes" for advisory "sparseness" XAT_SPARSE There's also some support for IMMUTABLE and APPENDONLY in illumos http://src.illumos.org/source/xref/illumos-gate/usr/src/uts/common/sys/vnode.h#643 http://src.illumos.org/source/xref/illumos-gate/usr/src/uts/common/sys/vnode.h#644 in case anything there helps. I bring these up just in hopes of avoiding unnecessary duplication of functionality in ways that might interfere with portability of datasets between ZFS implementations. On Thu, Jan 10, 2019 at 3:23 AM Jorgen Lundman <lund...@lundman.net> wrote: > > > To bring us up to date now, on the OsX and Windows platforms, I have > (internally) made the following reservations as compared to ZOL; > > We have no additional command-line options. > > File flags (zfs_znode.h) > > + /* Unsure how we officially register new flags bits, but > + * I guess we will claim the whole nibble for OSX > + * 0x00n0000000000000ull : n = 1 2 4 8 > + */ > +#define ZFS_TRACKED 0x0010000000000000ull > +#define ZFS_COMPRESSED 0x0020000000000000ull > +#define ZFS_SIMMUTABLE 0x0040000000000000ull > +#define ZFS_SAPPENDONLY 0x0080000000000000ull > > Although the UF_COMPRESSED might be a confusing name, it refers to HFS > decmpfs compression, that we (have to) track, and undo (asap!). The flag > can most likely be removed if the code is re-organised. > > On Windows we have: > > + /* Unsure how we officially register new flags bits, but > + * I guess we will claim the whole nibble for Windows > + * 0x0n00000000000000ull : n = 1 2 4 8 > + */ > +#define ZFS_REPARSEPOINT 0x0100000000000000ull > > With ioctl codes, Linux reserved +0x80 and FreeBSD +0xC0. I took +0xD0 for > OsX and +0xE0 for Windows. > > ZFS_IOC_PROXY_DATASET = ('Z' << 8) + 0xD0, > > ZFS_IOC_MOUNT = CTL_CODE(ZFSIOCTL_TYPE, 0x8E0 > ZFS_IOC_UNMOUNT = CTL_CODE(ZFSIOCTL_TYPE, 0x8E1 > ZFS_IOC_UNREGISTER_FS = CTL_CODE(ZFSIOCTL_TYPE, 0x8E2 > > I believe SA, zfs prop and zpool props do not affect on disk format, but we > define; > > ZPL_DXATTR, > + ZPL_ADDTIME, > + ZPL_DOCUMENTID, > ZPL_END > > These all have manpage changes. > > zprop_register_string(ZFS_PROP_SHAREAFP, "shareafp" > zprop_register_index(ZFS_PROP_APPLE_BROWSE, "com.apple.browse" > zprop_register_index(ZFS_PROP_APPLE_IGNOREOWNER, "com.apple.ignoreowner" > zprop_register_hidden(ZFS_PROP_APPLE_LASTUNMOUNT,"COM.APPLE.LASTUNMOUNT" > zprop_register_index(ZFS_PROP_APPLE_MIMIC_HFS, "com.apple.mimic_hfs" > zprop_register_index(ZFS_PROP_APPLE_DEVDISK, "com.apple.devdisk" > > zprop_register_string(ZFS_PROP_DRIVELETTER, "driveletter" > > Since there is no (easy) way to do automounted snapshot mounting, we have > extended the "zfs mount" (and unmount) commands to also accept snapshots. > Ie, "zfs mount pool/dataset@snapshot". The mountpoint location is the same. > > I may have missed a bunch :) > > Lund > > -- > Jorgen Lundman | <lund...@lundman.net> > Unix Administrator | +81 (0)90-5578-8500 > Shibuya-ku, Tokyo | Japan > ------------------------------------------ openzfs: openzfs-developer Permalink: https://openzfs.topicbox.com/groups/developer/T538929199ec54878-M6f1aa6a646af29b40b27c8e1 Delivery options: https://openzfs.topicbox.com/groups/developer/subscription
