Date: Mon, 19 Feb 2018 21:33:53 +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: <1dfe0d2b-48dd-3f99-8332-b3979faad45d@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/02/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.
Searching on 0xde did deliver indeed plenty 0xdeadc0de and sisters.
the resulting size is 32bit, so if it is a leftover of 0xdeadcode, it is
due to a not-32bit aligned access, since the 3 upper bytes are 0.
Only way to find this out is dig thru the code. :) But I'm no hero at that.
But there is atleast not a particular FS_ZFS_MAGIC!!
And there is no obvious definition what is returned in f_type??
--WjW
>>>>> struct statfs {
>>>>> uint32_t f_version; /* structure version number */
>>>>> uint32_t f_type; /* type of filesystem */
>>>>> uint64_t f_flags; /* copy of mount exported flags */
>>>>> ......
>>>>> }
>>>>>
>>>>> Any hints where to look would be welcomed.
>>>>>
>>>>> Thanx,
>>>>> --WjW
>>>> --
>>>> Bob Bishop
>>>> rb@gid.co.uk
>> --
>> Bob Bishop t: +44 (0)118 940 1243
>> rb@gid.co.uk m: +44 (0)783 626 4518
>
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?1dfe0d2b-48dd-3f99-8332-b3979faad45d>