Jorgen, how are the new windows file flags different from the existing ones, specifically:
ZFS_REPARSEPOINT -> ZFS_REPARSE ZFS_SIMMUTABLE -> ZFS_IMMUTABLE ZFS_SAPPENDONLY -> ZFS_APPENDONLY As I recall, these were implemented for CIFS/SMB. I would hope that local Windows access has the same semantics as over SMB, but who knows! If we're going to keep these in zp_flags, let's get PR's opened to reserve these on the other platforms, otherwise someone could use the same bit to mean something different and then you wouldn't be able to move pools between operating systems. --matt On Thu, Mar 21, 2019 at 1:18 PM Gordon Ross <gordon.w.r...@gmail.com> wrote: > 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 Given that userland binaries run on only one operating system, I think that it's fine for different OS's to have different IOCTL numbers, so we don't need to worry about these for compatibility. But it might make it slightly simpler to apply diffs from one platform to another. > > > > 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 > ------------------------------------------ openzfs: openzfs-developer Permalink: https://openzfs.topicbox.com/groups/developer/T538929199ec54878-M70f6a55112a4a319e25b51de Delivery options: https://openzfs.topicbox.com/groups/developer/subscription
