From owner-freebsd-fs@freebsd.org Sun Nov 4 07:58:35 2018 Return-Path: Delivered-To: freebsd-fs@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 335CD10F7B40 for ; Sun, 4 Nov 2018 07:58:35 +0000 (UTC) (envelope-from julian@freebsd.org) Received: from vps1.elischer.org (vps1.elischer.org [204.109.63.16]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "vps1.elischer.org", Issuer "CA Cert Signing Authority" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id 3C5BB7E2FF; Sun, 4 Nov 2018 07:58:34 +0000 (UTC) (envelope-from julian@freebsd.org) Received: from Julian-MBP3.local (c-73-225-95-163.hsd1.wa.comcast.net [73.225.95.163]) (authenticated bits=0) by vps1.elischer.org (8.15.2/8.15.2) with ESMTPSA id wA47wV9W018926 (version=TLSv1.2 cipher=DHE-RSA-AES128-SHA bits=128 verify=NO); Sun, 4 Nov 2018 00:58:32 -0700 (PDT) (envelope-from julian@freebsd.org) Subject: Re: How to fill in the fsid for file systems? To: Rick Macklem , Andriy Gapon , Konstantin Belousov Cc: FreeBSD Filesystems References: <20181030012240.GM5335@kib.kiev.ua> From: Julian Elischer Message-ID: Date: Sun, 4 Nov 2018 00:58:26 -0700 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.14; rv:52.0) Gecko/20100101 Thunderbird/52.9.1 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 8bit Content-Language: en-US X-Rspamd-Queue-Id: 3C5BB7E2FF X-Spamd-Result: default: False [0.07 / 200.00]; ARC_NA(0.00)[]; RCVD_VIA_SMTP_AUTH(0.00)[]; RECEIVED_SPAMHAUS_PBL(0.00)[163.95.225.73.zen.spamhaus.org : 127.0.0.10]; FROM_HAS_DN(0.00)[]; RCPT_COUNT_THREE(0.00)[4]; MIME_GOOD(-0.10)[text/plain]; DMARC_NA(0.00)[freebsd.org]; R_SPF_SOFTFAIL(0.00)[~all]; TO_MATCH_ENVRCPT_SOME(0.00)[]; TO_DN_ALL(0.00)[]; MX_GOOD(-0.01)[cached: mx66.freebsd.org]; NEURAL_HAM_SHORT(-0.81)[-0.806,0]; IP_SCORE(-0.01)[country: US(-0.06)]; FROM_EQ_ENVFROM(0.00)[]; R_DKIM_NA(0.00)[]; SUBJECT_ENDS_QUESTION(1.00)[]; ASN(0.00)[asn:36236, ipnet:204.109.60.0/22, country:US]; MID_RHS_MATCH_FROM(0.00)[]; RCVD_TLS_ALL(0.00)[]; RCVD_COUNT_TWO(0.00)[2] X-Rspamd-Server: mx1.freebsd.org X-BeenThere: freebsd-fs@freebsd.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Filesystems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 04 Nov 2018 07:58:35 -0000 On 1/11/18 7:24 pm, Rick Macklem wrote: > Andriy Gapon wrote >> On 31/10/2018 17:50, Rick Macklem wrote: >>> I alluded to this option in my last post. I think both fsids will need to be in the >>> mount structure, since finding the correct mount point via the fsid is the first >>> step in translating a file handle to a vnode. (After that VFS_FHTOVP() does the rest.) >>> >>> And I think it will get messy. A couple of examples. >>> There are some syscalls that use file handles. fhopen(2), fhstat(2), fhstatfs(2), >>> getfh(2), lgetfh(2) >>> I had assumed that the "file handles" used by these should be the same file >>> handles that NFS uses (ie. file handles are a generic VFS component and not NFS >>> specific) but I can see the argument either way. I actually don't know what >>> apps/utilities use fhopen/fhstat/fhstatfs, but getfh(2) is used by mountd. >>> Since mountd uses getfh(2) to get a file handle for NFS mounts, it needs to >>> return the NFS fsid to keep the old binaries working, even if you add a >>> new getnfsfh(2) function for mountd to use. >>> - Now you have some file handle system calls using file handles with the NFS >>> fsid in them and some using file handles with the "true" fsid in them. >>> (Sounds confusing to me.) >>> >>> Since the first step in turning a file handle into a vnode is looking up the fsid >>> in the mount list, if you had two fsids, I think they both would end up in the >>> mount structure so that lookup could be done easily. >>> This lookup is normally done by vfs_busyfs() { that appears to be the only use >>> of vfs_busyfs() in sys/kern. I haven't looked in the various file systems }. >>> With two fsids, you need two functions and need to be careful which one you use. >> I originally thought about having a separate filesystem list for NFS that would >> contain only exported filesystems. But I suspect that managing it could be >> problematic. >> >> An alternative idea is to use osd(9) framework to attach NFS specific data to >> struct mount without modifying the structure and without exposing the NFS data >> to other consumers. > I have two comments. The first is related to the above and the second is a big > picture question related to doing this. > > Specifically w.r.t. the above. I probably rambled and didn't make what I was > trying to say clear, so I'll try again... > - getfh(2) returns a file handle that is used for NFS, but is also used for system > calls (fhopen(2), fhstat(2) and fhstatfs(2)) that are not related to NFS. > --> A file handle isn't really NFS specific, although NFS is the big user of it. > If the above is correct, then it seems that there should only be one kind of file handle. > --> Since the fsid is a key part of a file handle, one kind of file handle implies one > kind of fsid. > I just think trying to create two kinds of fsid and two kinds of file handle would > make the code confusing and unnecessarily complex. > > On the big picture..the more I look at this, the less obvious the usage of setting > an fsid other than what the file system sets seems to become. I thought the usage > of this was to ensure that when a file system was moved (just moving the storage > hardware or a block by block cloning) to a different system, the same fsid would > be used so that file handles wouldn't change. Note that a file handle also has > a fileid number (think I-node#) in it, so the file system "move" can't change the > file system's structure. > - UFS keeps the fsid in the superblock, so moving the file system should retain > the same fsid value. (There might be an obscure case of another file system > having the same fsid, so it has to change. However, since newfs(8) uses the > creation time and a random# to create it, a conflict seems highly unlikely.) > - This leaves ZFS. I know nothing about ZFS, but a glance at the code seems > to indicate it normally comes out of the "physical dataset" field ds_fsid_guid. > --> Does this mean it changes when "moved" or stays the same, like UFS? > If the answer is "stays the same", I don't see that being able to manually set > the fsid is useful? > (There are file systems like cd9660 and msdosfs where the fsid will change, > but I don't see those used a storage for NFS servers where they might be > moved/cloned/…) > > Maybe someone can explain when it would be useful for FFS (or not)? SO lets' just make the usage model clear: I believe that what Josh needs is to have a  two High availability servers viewing a single (cloud based) filesystem, export the same FSID so that when one takes over for the other the clients don't notice. The second usage is that over a reboot an NFS client may not notice (if there were no transactions while the system was down). Even if for some reason the file systems came up in a different order.. > > rick > > _______________________________________________ > freebsd-fs@freebsd.org mailing list > https://lists.freebsd.org/mailman/listinfo/freebsd-fs > To unsubscribe, send any mail to "freebsd-fs-unsubscribe@freebsd.org" > >