Date: Mon, 19 Feb 2018 23:03:19 +0100 From: Willem Jan Withagen <wjw@digiware.nl> To: Andriy Gapon <avg@FreeBSD.org>, "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: <8134dba0-fdae-0109-4bae-3441d750566d@digiware.nl> In-Reply-To: <45bd4a05-406b-d6ac-6679-6897ab1fc742@FreeBSD.org> References: <456B0CAA-367F-478A-BB61-153942C3EB7A@gid.co.uk> <201802191833.w1JIXhVL078022@pdx.rh.CN85.dnsmgr.net> <45bd4a05-406b-d6ac-6679-6897ab1fc742@FreeBSD.org>
next in thread | previous in thread | raw e-mail | index | archive | help
On 19-2-2018 22:20, Andriy Gapon wrote: > On 19/02/2018 20:33, Rodney W. Grimes wrote: >>> Hi, >>> >>>> On 19 Feb 2018, at 15:50, Willem Jan Withagen <wjw@digiware.nl> wrote: > >>>> 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. > > This is simpler, I think. > It is a hash value (calculated using a specific algorithm) of a filesystem type > name. See vfs_register(). Right in vfs_init.c > There are no magic predefined constants for the types. It is a bit of work doing the hashes, but there could very well be pre-calculated FS_<fs>_TYPE defines. See my other post. > BTW, lsvfs(1) and its source code could be of interest to the original poster. > E.g., getvfsbyname(3). lsvfs output could even be used to generate part of the ENUM list. --WjW
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?8134dba0-fdae-0109-4bae-3441d750566d>