From owner-freebsd-fs@freebsd.org Sun Nov 4 15:38:17 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 EE1F810DA770 for ; Sun, 4 Nov 2018 15:38:16 +0000 (UTC) (envelope-from rmacklem@uoguelph.ca) Received: from CAN01-TO1-obe.outbound.protection.outlook.com (mail-eopbgr670066.outbound.protection.outlook.com [40.107.67.66]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (Client CN "mail.protection.outlook.com", Issuer "GlobalSign Organization Validation CA - SHA256 - G3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 127C3764F8; Sun, 4 Nov 2018 15:38:14 +0000 (UTC) (envelope-from rmacklem@uoguelph.ca) Received: from YTOPR0101MB1162.CANPRD01.PROD.OUTLOOK.COM (52.132.50.155) by YTOPR0101MB1308.CANPRD01.PROD.OUTLOOK.COM (52.132.45.23) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.1294.28; Sun, 4 Nov 2018 15:38:13 +0000 Received: from YTOPR0101MB1162.CANPRD01.PROD.OUTLOOK.COM ([fe80::9c71:6eb6:1bff:727b]) by YTOPR0101MB1162.CANPRD01.PROD.OUTLOOK.COM ([fe80::9c71:6eb6:1bff:727b%3]) with mapi id 15.20.1294.028; Sun, 4 Nov 2018 15:38:13 +0000 From: Rick Macklem To: Julian Elischer , Andriy Gapon , Konstantin Belousov CC: FreeBSD Filesystems Subject: Re: How to fill in the fsid for file systems? Thread-Topic: How to fill in the fsid for file systems? Thread-Index: AQHUb557F1RNqdJl0kuwS+F5J/DjsKU2/twAgAGdwkKAAGQrgIAAehmGgAELs4CAATs6uIADh0gAgAB6NSw= Date: Sun, 4 Nov 2018 15:38:13 +0000 Message-ID: References: <20181030012240.GM5335@kib.kiev.ua> , In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: spf=none (sender IP is ) smtp.mailfrom=rmacklem@uoguelph.ca; x-ms-publictraffictype: Email x-microsoft-exchange-diagnostics: 1; YTOPR0101MB1308; 6:ZgvyleSHiqCWiv9XxRZRlP27nUS3Qp5ZAbMMvgZ6NsLOwW8C75g4ShweZANJ2Aws2lIglxS2It1hqQNDf4C9KHT0u+vmS6OevrXiWWawsGzyVO4xdgwIu+U+Kmn8i8J4aKFh6pPNEGxno3McOq//ODwN+K6XCk3BwuKrZaZmF9mqEQNngmO60swsRJK4FED1JMvL2TBR8tEecn5B9Zsv42WyHvL3MjWZk5ArNIanSVnAfn8Qu/vSN/TNArunOeJPSy9cdAGOc+lAwnT2/rLZ7xUwWlq2h83dv2Al4pTHha3IkS3JnyCQJD0jc7A+3gFZwlF9vBgnEd20UkKhRmUTUHDCMTLHpqK0+NHyWWvRV+x2CyREUFVtN3Vw/JUh7B3jE1uV92r+OOvo9dHKhRu7ONYXcbM1wWQ1H6YgZqu2V57btBf+VKpKFqxSCYPdyOcLY+p3tx6kZFqyjOOU8Owt+w==; 5:pWmpYMiNRuj+KwkjyyQQfC610wiIa2Fckem8El4odNjJoXLlTQCLDYUx6ENCRQAhctyJsFpe5gAOyI6SLGpcRXs5W6BfWF6PGwlV2G78qOGR8burxHk/Maj9nYxd+JyUD6DqtJIkvoXVYsYzUFVp2o2r8c7yuebdhKfwFuCdJ28=; 7:AwIOKgi2s7dr75AbhLBs3ll6+u3kEIm0tQ/loTxMBb7RQs88qcy30SLN/1LWEhNWPZUOXSP5j2lEXmsFo0G6Nr5tsVD0tTtTcz45v1UZHWgsp5jZojMlzyLYP53NF9QGe9vwvbmHBpbWJGIFyoPPdQ== x-ms-exchange-antispam-srfa-diagnostics: SOS; x-ms-office365-filtering-correlation-id: 70fd35d0-0827-4ee8-d2df-08d6426b8861 x-microsoft-antispam: BCL:0; PCL:0; RULEID:(7020095)(4652040)(8989299)(5600074)(711020)(4534185)(4627221)(201703031133081)(201702281549075)(8990200)(2017052603328)(7153060)(7193020); SRVR:YTOPR0101MB1308; x-ms-traffictypediagnostic: YTOPR0101MB1308: x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:; x-ms-exchange-senderadcheck: 1 x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(6040522)(2401047)(5005006)(8121501046)(3231382)(944501410)(52105095)(93006095)(93001095)(10201501046)(3002001)(148016)(149066)(150057)(6041310)(201703131423095)(201702281529075)(201702281528075)(20161123555045)(201703061421075)(201703061406153)(20161123558120)(20161123562045)(20161123564045)(20161123560045)(201708071742011)(7699051)(76991095); SRVR:YTOPR0101MB1308; BCL:0; PCL:0; RULEID:; SRVR:YTOPR0101MB1308; x-forefront-prvs: 084674B2CF x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(396003)(346002)(376002)(136003)(366004)(39860400002)(189003)(199004)(106356001)(53936002)(105586002)(8936002)(81156014)(55016002)(81166006)(5660300001)(6436002)(6246003)(8676002)(9686003)(68736007)(33656002)(186003)(305945005)(74316002)(97736004)(71200400001)(71190400001)(76176011)(46003)(99286004)(7696005)(486006)(11346002)(446003)(476003)(2900100001)(74482002)(110136005)(93886005)(316002)(786003)(6506007)(478600001)(102836004)(4326008)(2906002)(86362001)(229853002)(25786009)(14454004)(39060400002)(256004)(14444005); DIR:OUT; SFP:1101; SCL:1; SRVR:YTOPR0101MB1308; H:YTOPR0101MB1162.CANPRD01.PROD.OUTLOOK.COM; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; MX:1; A:1; received-spf: None (protection.outlook.com: uoguelph.ca does not designate permitted sender hosts) x-microsoft-antispam-message-info: jxwyZO071d2J7lG38v5WmXE3B6INHBUQZzgUfgVm6LW0mRRL344gfq3pG8nLpNeztsJqD3gwdNHwnTGcCK8tuKvYG1XhJNmxqpBhoCsY+pmtbnWxVFUmrqkPGIVhhKbTP6/BHYbe0pB49MqJIsdK8n7Z735DiJhomStRPZn5U256+ir+I3CQOt1c7xkBTPwgXBHav5E7+63U5H3jTng5tVtIznW9nfVhSH2fMeRqPzVW+WX+FcMlMO40nvblzvaW30CzNPK6nJsLR/o8J/Mz8ysfU9toz8fxgBvJsxmC1t+RNwWBC2uQXHgCuz0PN3k/z7SQT4EcsVy5KXp/iFWrvW+FbRvyhDiUtAKXxqfQe5w= spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginatorOrg: uoguelph.ca X-MS-Exchange-CrossTenant-Network-Message-Id: 70fd35d0-0827-4ee8-d2df-08d6426b8861 X-MS-Exchange-CrossTenant-originalarrivaltime: 04 Nov 2018 15:38:13.5768 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: be62a12b-2cad-49a1-a5fa-85f4f3156a7d X-MS-Exchange-Transport-CrossTenantHeadersStamped: YTOPR0101MB1308 X-Rspamd-Queue-Id: 127C3764F8 X-Spamd-Result: default: False [-0.79 / 200.00]; ARC_NA(0.00)[]; FROM_HAS_DN(0.00)[]; RCPT_COUNT_THREE(0.00)[4]; R_SPF_ALLOW(-0.20)[+ip4:40.107.0.0/17]; MIME_GOOD(-0.10)[text/plain]; DMARC_NA(0.00)[uoguelph.ca]; RCVD_COUNT_THREE(0.00)[3]; TO_MATCH_ENVRCPT_SOME(0.00)[]; TO_DN_ALL(0.00)[]; MX_GOOD(-0.01)[mx2.hc184-76.ca.iphmx.com,mx1.hc184-76.ca.iphmx.com,mx2.hc184-76.ca.iphmx.com,mx1.hc184-76.ca.iphmx.com,mx2.hc184-76.ca.iphmx.com,mx1.hc184-76.ca.iphmx.com,mx2.hc184-76.ca.iphmx.com,mx1.hc184-76.ca.iphmx.com,mx2.hc184-76.ca.iphmx.com,mx1.hc184-76.ca.iphmx.com,mx2.hc184-76.ca.iphmx.com,mx1.hc184-76.ca.iphmx.com,mx2.hc184-76.ca.iphmx.com,mx1.hc184-76.ca.iphmx.com,mx2.hc184-76.ca.iphmx.com,mx1.hc184-76.ca.iphmx.com,mx2.hc184-76.ca.iphmx.com,mx1.hc184-76.ca.iphmx.com,mx2.hc184-76.ca.iphmx.com,mx1.hc184-76.ca.iphmx.com,mx2.hc184-76.ca.iphmx.com,mx1.hc184-76.ca.iphmx.com,mx2.hc184-76.ca.iphmx.com,mx1.hc184-76.ca.iphmx.com,mx2.hc184-76.ca.iphmx.com,mx1.hc184-76.ca.iphmx.com]; NEURAL_HAM_SHORT(-0.89)[-0.894,0]; RCVD_IN_DNSWL_NONE(0.00)[66.67.107.40.list.dnswl.org : 127.0.3.0]; IP_SCORE(-0.58)[asn: 8075(-2.84), country: US(-0.07)]; FROM_EQ_ENVFROM(0.00)[]; R_DKIM_NA(0.00)[]; SUBJECT_ENDS_QUESTION(1.00)[]; ASN(0.00)[asn:8075, ipnet:40.64.0.0/10, country:US]; RCVD_TLS_LAST(0.00)[] 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 15:38:17 -0000 Julian Elischer wrote: [stuff snipped] >Rick Macklem wrote: >> >> 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. Well, for UFS/FFS, if it is the same physical storage or the file system wa= s cloned via a block for block copy (like using dd(1)), then it shouldn't be a probl= em, since the fsid comes out of the superblock. That leaves ZFS, which is what I was asking. I don't understand the ZFS code well enough to understand what dmu_objset_fsid_guid() is doing to get the fsid. I also don't know if the v= alue changes for snaphots of the same file system? - If it does ever change, then that is the usage case for this option. I suppose there is nullfs. It uses vfs_getnewfsid() to fill in the fsid, so= if a nullfs mount were exported instead of the underlying UFS or ZFS file system, this option would be needed. (I think it would be wiser to just avoid exporting the nullfs mount, but some might have a use of this?). > 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.. This should be fine for all the file system types (UFS, cd9660, msdosfs) th= at I have checked, except maybe ZFS. Other than UFS, they mostly use vfs_getnewf= sid(), which should return the same value for a given file system type. (I don't think anyone really cares about cd9660, msdosfs w.r.t. this anyhow= .) Again, ZFS is the one I don't know enough about. So, the question really was "what does ZFS do to generate the fsid?". Now, Panzura does something else w.r.t. fsid, but that isn't a generic Free= BSD issue. rick