This isn't point-and-click use is a filesystem that cannot be exported over network? Saying something is 'hackish' and then suggesting that sysadmins 'sort it out in rc.local' isn't constructive. Please provide a better one or show where exactly am I incorrect. Perhaps, but it's not our responsibility to correct for bugs/issues in other software. Since it's ZFS that's 'special', I will argue that it is its own responsibility to provide the functionality required for other parts of the system to continue to function. When ZoL filesystem needs to be exported over NFS4, a bind mount must be created. The majority (?) isn't even using NFS, so why force ZoL to go around kludges in another piece of software (nfs daemon etc)? Soon(er than later), we'd have to do the same for iSCSI, Samba and what not. The init script(s) is complicated enough as it is without adding even more complexity (that will have to be maintained - for a very limited number of users). Why should we force stuff upon the majority, which only the minority is using? It is, if the majority isn't using bind mounts. Don't they have another way of executing local code, much like rc.local? Even more, systemd based distributions (good luck finding one without it these days) won't have it by definition.įair enough. Saying something is 'hackish' and then suggesting that sysadmins 'sort it out in rc.local' isn't /etc/rc.local does not exist and is not called in all distributions. If you don't like my solution, that's fine, please provide a better one or show where exactly am I incorrect. No standard mechanism in GNU/Linux will allow for it if the filesystem is not present in /etc/fstab. Even more, systemd based distributions (good luck finding one without it these days) won't have it by definition.Īre you suggesting that instead of editing a config file (present, documented) you would rather ask everyone to roll their own code, manually create bind mounts? That doesn't sound like a sane systems management practice. The /etc/zfs/binds file would look like /etc/rc.local does not exist and is not called in all distributions. $MODE may look redundant but perhaps could be kept for future expansion, maybe there could be other bind types. Log_begin_msg "Unmounting ZFS filesystems" Aborting." + exit 4 + + esac + done + fi + + # Create (optional) binds to the NFS4 export tree + if then + log_begin_msg "Binding NFS4 mounts" + sed -e "s/#.*//" -e "/^$/d" $ZFS_NFS4_BINDS | while read LINE + do + MODE="`echo $LINE | awk ''`" + umount $DEST + log_end_msg $? + + *) echo "Unknown bind mode ($MODE) in $ZFS_NFS4_BINDS. Personally (sysadmin cap on) /etc/zfs/binds would work for me (together with a bit of parsing in /etc/init.d/zfs) as it's sufficiently low-tech and doesn't require changes in the actual zfs stack. Perhaps a file in /etc/zfs/ like 'binds' would work. Perhaps localfs should depend on zfs and not the other way around.Īlternatively, the zfs service should parse some file that will tell it how the binds go and bind after mounting the zfs filesystem. I don't think this is a bug in zfs rather a race condition between the distribution's native localfs init script and zfs. On the server, the confused administrator will see the actual zfs and will scratch their head. The clients will see the contents of an empty directory as the exporter uses the / bind mount. When the system boots, a bind-type mount will be created from /storage/pmr to /exports/pmr which is effectively mounting the underlying filesystem (most likely / ) to the bind point and exporting that. storage/pmr /exports/pmr none rw,bind 0 0
0 Comments
Leave a Reply. |
AuthorWrite something about yourself. No need to be fancy, just an overview. ArchivesCategories |