On Fri, Aug 25, 2017 at 08:11:05AM +1000, NeilBrown wrote:
>
> Just to provide contrast, NFS has a config file which can provide
> certain defaults for mounted filesystems. However it doesn't require a
> udev event to achieve this.
I think we're mixing multiple things, and that may be confusing the
discussion. A config file parser is a technology. *How* you use the
config file parser can be quite different even if it is using the same
config file parser or config file format.
>From what I've seen in this e-mail thread, there are at least three
different use cases:
1) How mkfs uses to create the file system
2) How the file system should be configured when/while it is mounted
3) Message marshalling and unmarshalling when communicating with the
kernel via uevents
> Instead, it provides "/sbin/mount.nfs" which imposes the defaults at
> mount time, rather than just after mount time.
>
> There could, conceivably, be an "/sbin/mount.xfs" which read the config
> file and set all the defaults concurrently with the mount operation.
For nfs there are a large number of knobs that are of interest at
mount time, such that specifying them all as mount options on the
command line, or in /etc/fstab, gets spectacularly painful. Which is
why /etc/nfsmount.conf makes sense.
For ext4 and nfs we have many more knobs that come into play when the
file system is created, and so for ext4 that's why I have
/etc/mke2fs.conf, where I might have some complex stanzas such as:
hugefile = {
features = extent,huge_file,bigalloc,flex_bg,uninit_bg,dir_nlink,extra_isize,^resize_inode,sparse_super2
cluster_size = 32768
hash_alg = half_md4
reserved_ratio = 0.0
num_backup_sb = 0
packed_meta_blocks = 1
make_hugefiles = 1
inode_ratio = 4194304
hugefiles_dir = /huge-dir
hugefiles_name = huge-data
hugefiles_digits = 0
hugefiles_size = 0
hugefiles_align = 256M
hugefiles_align_disk = true
num_hugefiles = 1
zero_hugefiles = false
flex_bg_size = 262144
}
...and then the sysadmin only has to type "mke2fs -T hugefile
/dev/sdc3" (for example).
The question of using the same parser for uevents is yet another can
of worms. And there, I think we need to be careful about what the
requirements are for these uevents. Uevents is just the technology.
There are many use cases for that technology; are you using them to
signal mounts/unmounts? And at the file system level or at the mount
namespace level?
Are you using them to single file system corruption problems? And if
so, are you trying to trying to send a single bit of information ---
"the file system is corrupted"? Or are you trying to send much more
information --- for example, sending each inode that file system found
that was corrupted, and each block number where the SCSI device found
a media error? (We have a solution that does this inside Google, and
it uses a netlink socket to do the delievery. I'm pretty sure that if
you used uevents, udev could melt down if there are a large number of
errors reported.)
And then the final question here is how much does standardization
help? Are there use cases where progams really want to use the same
format when updating /etc/mke2fs.conf versus /etc/nfsmount.conf versus
/etc/mkfs.xfs.conf? Or is this more of, "let's try to make life
slightly easier for the user by keeping things mostly the same as we
can"? Or is this just a matter of file system developers sharing
their experiences of various different designs, just so that they are
aware of what libaries or code bases are available for them to use?
Cheers,
- Ted
--
To unsubscribe from this list: send the line "unsubscribe linux-xfs" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
