Date: Mon, 19 Feb 2018 22:55:37 +0100 From: Willem Jan Withagen <wjw@digiware.nl> To: "Rodney W. Grimes" <freebsd-rwg@pdx.rh.CN85.dnsmgr.net>, rb@gid.co.uk Cc: FreeBSD Hackers <freebsd-hackers@freebsd.org> Subject: Re: Using fstatfs on a ZFS disk Message-ID: <82ef8d5d-ef62-f746-f415-728e34257924@digiware.nl> In-Reply-To: <201802191833.w1JIXhVL078022@pdx.rh.CN85.dnsmgr.net> References: <201802191833.w1JIXhVL078022@pdx.rh.CN85.dnsmgr.net>
next in thread | previous in thread | raw e-mail | index | archive | help
On 19-2-2018 19:33, Rodney W. Grimes wrote:
>> Hi,
>>
>>> On 19 Feb 2018, at 15:50, Willem Jan Withagen <wjw@digiware.nl> wrote:
>>>
>>> On 19-2-2018 16:00, Bob Bishop wrote:
>>>> Hi,
>>>>> On 19 Feb 2018, at 14:48, Willem Jan Withagen <wjw@digiware.nl> wrote:
>>>>>
>>>>> Hi,
>>>>>
>>>>> I'm trying to find the values of the returned f_type for ZFS
>>>>> in the fstatfs call when a file is on ZFS....
>>>>>
>>>>> But I have not yet found the definitions of the ENUMS that
>>>>> would fill that value... Let alone the value for ZFS.
>>>> I chased this particular wild goose myself recently. It?s FS_... in /usr/include/sys/disklabel,h that you want.
>>>
>>> Hi Bob,
>>>
>>> I grepped on MAGIC and FS, but the combo did not deliver anything useful. So this is already more that I found.
>>> I did get:
>>> /usr/include/ufs/ffs/fs.h:#define FS_UFS1_MAGIC 0x011954 /* UFS1 fast filesystem magic number */
>>> /usr/include/ufs/ffs/fs.h:#define FS_UFS2_MAGIC 0x19540119 /* UFS2 fast filesystem magic number */
>>> /usr/include/ufs/ffs/fs.h:#define FS_BAD_MAGIC 0x19960408 /* UFS incomplete newfs magic number */
>>
>> Those I believe are magic numbers for UFS superblocks...
>>
>>> So I was looking for something like: FS_ZFS_MAGIC
>>
>> ... so you won?t find that.
>>
>>> disklabel.h contains:
>>> #ifdef FSTYPENAMES
>>> static const char *fstypenames[] = {
>>>
>>> And further search:
>>> /usr/include/sys/disk/bsd.h:#define FS_ZFS 27 /* Sun's ZFS */
>>>
>>> Running:
>>> #include "stdio.h"
>>>
>>> #include <sys/param.h>
>>> #include <sys/mount.h>
>>>
>>> int main() {
>>> struct statfs fstr;
>>> char * str;
>>>
>>> str = "/tmp";
>>> statfs(str, &fstr);
>>> printf("%s, ftype: 0x%x.\n", str, fstr.f_type);
>>> }
>>> results in:
>>> /tmp, ftype: 0xde.
>>>
>>> Now 0xde != 27, so the question is, where is this 0xde specified.
>>> And more important is this f_type constant over all FreeBSD ZFS filesystems?
>>
>> You got me. And a quick look at sys/kern/vfs_syscalls.c doesn?t help except to imply that the type is set when the filesystem is mounted. I have no idea where 0xde comes from.
>
> Could that 0xde be the start of 0xdeadcode?
>
> 0xde is 222 decimal, that does not ring a bell for me either.
Well the VSTAT node gets setup during vfs_mount_alloc() which copies
data from:
/*
* Filesystem configuration information. One of these exists for each
* type of filesystem supported by the kernel. These are searched at
* mount time to identify the requested filesystem.
*
* XXX: Never change the first two arguments!
*/
struct vfsconf {
u_int vfc_version; /* ABI version number */
char vfc_name[MFSNAMELEN]; /* filesystem type name */
struct vfsops *vfc_vfsops; /* filesystem operations vector */
int vfc_typenum; /* historic filesystem type number */
int vfc_refcount; /* number mounted of this type */
int vfc_flags; /* permanent flags */
struct vfsoptdecl *vfc_opts; /* mount options */
TAILQ_ENTRY(vfsconf) vfc_list; /* list of vfscons */
};
And the "historic filesystem type number" is a worrying comment.
As it turns out the type is calculated/hashed in vfs_init:
====
if (vfs_typenumhash != 0) {
/*
* Calculate a hash on vfc_name to use for vfc_typenum. Unless
* all of 1<->255 are assigned, it is limited to 8bits since
* that is what ZFS uses from vfc_typenum and is also the
* preferred range for vfs_getnewfsid().
*/
hashval = fnv_32_str(vfc->vfc_name, FNV1_32_INIT);
hashval &= 0xff;
secondpass = 0;
do {
/* Look for and fix any collision. */
TAILQ_FOREACH(tvfc, &vfsconf, vfc_list) {
if (hashval == tvfc->vfc_typenum) {
if (hashval == 255 && secondpass == 0) {
hashval = 1;
secondpass = 1;
} else
hashval++;
break;
}
}
} while (tvfc != NULL);
vfc->vfc_typenum = hashval;
if (vfc->vfc_typenum >= maxvfsconf)
maxvfsconf = vfc->vfc_typenum + 1;
So the f_type is sort of stable over time, unless een new type creates a
collision and things start moving.
Made a small test program:
/tmp, ftype: 0xde, name: zfs.
/home/wjw, ftype: 0x3a, name: nfs.
/home/wjw/.tcshrc, ftype: 0x3a, name: nfs.
/dev/random, ftype: 0x71, name: devfs.
So I guess I'm going to '#define FS_ZFS_TYPE 0xde'
--WjW
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?82ef8d5d-ef62-f746-f415-728e34257924>