Date: Thu, 21 Nov 2019 08:08:29 -0700 From: Alan Somers <asomers@freebsd.org> To: Borja Marcos <borjam@sarenet.es> Cc: freebsd-fs <freebsd-fs@freebsd.org> Subject: Re: ZFS snapdir readability (Crosspost) Message-ID: <CAOtMX2hUCAXRzjsZUWg3h1kFQ-U_%2BQYbuRr1D_1bQ43CW55fRg@mail.gmail.com> In-Reply-To: <A2C18B9B-C3CF-4874-962D-A4CE496FC8EA@sarenet.es> References: <20191107004635.c6d2e7d464d3d556a0d87465@magnetkern.de> <CAOtMX2huHZcXHH%2B=3Bx7hX_p9udJ2acOX%2BZL8vW=pjqbe6mOAA@mail.gmail.com> <e2eecef7-21b6-0ff2-b259-71421b7d097c@sentex.net> <9B22AD46-BE87-4305-9638-74D23AD4C8CA@sarenet.es> <cfcc12dd-e9eb-5a98-a031-ab18436a2dd3@sentex.net> <261FE331-EC5C-48C8-9249-9BCBF887CE38@sarenet.es> <913f7040-6e38-452d-6187-e17fae63b652@sentex.net> <20191120144041.7f916360dc0c69bf509c9bd1@magnetkern.de> <AEF4CA02-36B3-42FC-BE92-14DF0AF99540@sarenet.es> <20191120163437.691abd369ab9c0a6d7d45ff2@magnetkern.de> <CF38B478-3638-4C18-B69F-E589DE9BBB95@sarenet.es> <20191120175803.03401c3316fe756cc46f79f1@magnetkern.de> <3C5DC6DD-C44B-41EE-B7AB-6D8F94E43174@sarenet.es> <201911211259.xALCxShX008743@higson.cam.lispworks.com> <462E2C53-2490-4B8C-BB54-BCE8B75BAEB0@sarenet.es> <CAMsT2=nBEiaiBNMD9_j1JNBwDueq8anOa2rtO_jPFoRcm0_uDA@mail.gmail.com> <51805C8F-75D6-4DA1-A28E-68DAFC8A0276@sarenet.es> <A2C18B9B-C3CF-4874-962D-A4CE496FC8EA@sarenet.es>
next in thread | previous in thread | raw e-mail | index | archive | help
On Thu, Nov 21, 2019 at 8:01 AM Borja Marcos <borjam@sarenet.es> wrote: > > > > On 21 Nov 2019, at 15:57, Borja Marcos <borjam@sarenet.es> wrote: > > > > ZFS originally didn=E2=80=99t offer any mechanism to mount snapshots ex= plicitly. > Except by cloning. > > Hmm. Looking at > https://github.com/zfsonfreebsd/ZoF/blob/projects/zfsbsd/cmd/mount_zfs/mo= unt_zfs.c > > snippet 1 > =E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94 > > /* try to open the dataset to access the mount point */ > if ((zhp =3D zfs_open(g_zfs, dataset, > ZFS_TYPE_FILESYSTEM | ZFS_TYPE_SNAPSHOT)) =3D=3D NULL) { > (void) fprintf(stderr, gettext("filesystem '%s' cannot be= " > "mounted, unable to open the dataset\n"), dataset); > libzfs_fini(g_zfs); > return (MOUNT_USAGE); > } > =E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94 > > snippet 2 > =E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94 > > /* treat all snapshots as legacy mount points */ > if (zfs_get_type(zhp) =3D=3D ZFS_TYPE_SNAPSHOT) > (void) strlcpy(prop, ZFS_MOUNTPOINT_LEGACY, > ZFS_MAXPROPLEN); > else > (void) zfs_prop_get(zhp, ZFS_PROP_MOUNTPOINT, prop, > sizeof (prop), NULL, NULL, 0, B_FALSE); > =E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94= =E2=80=94=E2=80=94=E2=80=94 > > Does this really make sense? Workaround (setting its mountpoint as legacy= ) > in order to break > previous behavior? I don=E2=80=99t see the problem in cloning snapshots i= n order > to mount them. But this > looks like something that can bite back in the future! > No, you're misunderstanding something. Nothing weird is required to manually mount a snapshot. You don't have to change its properties, nor does it happen automatically. The code you're looking at only relates to the in-memory copy of the mountpoint property, a property that snapshots don't have. -Alan
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?CAOtMX2hUCAXRzjsZUWg3h1kFQ-U_%2BQYbuRr1D_1bQ43CW55fRg>