Hello!
I must admit that when I was working on REPARSE, I just straight up assumed I had to create things myself, since "I was first" on Windows. That is my bad. I already have a user pointing this out, that we should be compatible with SMB; https://github.com/openzfsonwindows/ZFSin/issues/107 Which is a good idea, and I will rollback the use of SA_SYMLINK and implement as XATTR. If XAT_REPARSE also exists, we should use it. I have never used XAT_* sections of ZFS sources on either platforms (OSX, Windows). I am keen on supporting the existing format for REPARSE points in SMB, so hopefully I can use illumos implementation for testing, and correctness. Please feel free to add comments to the ticket, so it doesn't look like it is ignored. ZFS_SIMMUTABLE -> ZFS_IMMUTABLE ZFS_SAPPENDONLY -> ZFS_APPENDONLY This is something that was added on OSX, as it has a concept of User and System bits for the flags - but now I'm concerned I did not look hard enough and there already are bits for it? man chflags on OSX: sappnd, sappend set the system append-only flag (super-user only) schg, schange, simmutable set the system immutable flag (super-user only) uappnd, uappend set the user append-only flag (owner or super-user only) uchg, uchange, uimmutable set the user immutable flag (owner or super-user only) I made a judgement call that ZFS_IMMUTABLE be most like uimmutable as a user in illumos can set immutable on their own files. Whereas simmutable is for root only. Sincerely, Lund Matthew Ahrens wrote: > 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 <[email protected] > <mailto:[email protected]>> 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 <[email protected] > <mailto:[email protected]>> 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 | <[email protected] > <mailto:[email protected]>> > > 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 <https://openzfs.topicbox.com/latest>* / openzfs-developer / see > discussions <https://openzfs.topicbox.com/groups/developer> + participants > <https://openzfs.topicbox.com/groups/developer/members> + delivery options > <https://openzfs.topicbox.com/groups/developer/subscription> Permalink > <https://openzfs.topicbox.com/groups/developer/T538929199ec54878-Ma7527fce2c3de46712522fd5> > -- Jorgen Lundman | <[email protected]> Unix Administrator | +81 (0)90-5578-8500 Shibuya-ku, Tokyo | Japan ------------------------------------------ openzfs: openzfs-developer Permalink: https://openzfs.topicbox.com/groups/developer/T538929199ec54878-M8f4a0a28e073794eaa1f1c7c Delivery options: https://openzfs.topicbox.com/groups/developer/subscription
