On 10/03/2021 08:09, Ulli Horlacher wrote:
> On Wed 2021-03-10 (07:59), Hugo Mills wrote:
>>> On tsmsrvj I have in /etc/exports:
>>> /data/fex       tsmsrvi(rw,async,no_subtree_check,no_root_squash)
>>> This is a btrfs subvolume with snapshots:
>>> root@tsmsrvj:~# btrfs subvolume list /data
>>> ID 257 gen 35 top level 5 path fex
>>> ID 270 gen 36 top level 257 path fex/spool
>>> ID 271 gen 21 top level 270 path fex/spool/.snapshot/2021-03-07_1453.test
>>> ID 272 gen 23 top level 270 path fex/spool/.snapshot/2021-03-07_1531.test
>>> ID 273 gen 25 top level 270 path fex/spool/.snapshot/2021-03-07_1532.test
>>> ID 274 gen 27 top level 270 path fex/spool/.snapshot/2021-03-07_1718.test
>>> root@tsmsrvj:~# find /data/fex | wc -l
>>> 489887
>>    I can't remember if this is why, but I've had to put a distinct
>> fsid field in each separate subvolume being exported:
>> /srv/nfs/home     -rw,async,fsid=0x1730,no_subtree_check,no_root_squash
> I must export EACH subvolume?!

I have had similar problems. I *think* the current case is that modern
NFS, using NFS V4, can cope with the whole disk being accessible without
giving each subvolume its own FSID (which I have stopped doing).

HOWEVER, I think that find (and anything else which uses fsids and inode
numbers) will see subvolumes as having duplicated inodes.

> The snapshots are generated automatically (via cron)!
> I cannot add them to /etc/exports

Well, you could write some scripts... but I don't think it is necessary.
I *think* it is only necessary if you want `find` to be able to cross
between subvolumes on the NFS mounted disks.

However, I am NOT an NFS expert, nor have I done a lot of work on this.
I might be wrong. But I do NFS mount my snapshots disk remotely and use
it. And I do see occasional complaints from find, but I live with it.

Reply via email to