On 2015-09-23 09:28, David Sterba wrote:
Possibly, but that depends on how you view things. Internally, subvolumes are independent of each other, but to a regular user (or anything that just uses the VFS layer), they look hierarchical, and as such without knowing the internals of the FS (which no regular user should need to know) I would expect the profile to propagate down from the (apparently) next higher subvolume.On Tue, Sep 22, 2015 at 03:39:30PM +0000, Hugo Mills wrote:The way I would expect things to work is that a new subvolume inherits it's properties from it's parent (if it's a snapshot),Definitely this.or from the next higher subvolume it's nested in.I don't think I like this. I'm not quite sure why, though, at the moment.I don't like inheritance from other than the parent subvolume because this makes things less obvious.
It's worth noting that I mean that it should just copy the properties from the next higher subvolume at creation, and if the next higher subvolume doesn't have the properties set, then just use the filesystem defaults (and don't try to walk back up more than one level).
Ideal situation in my opinion WRT block-group profile inheritance would be that when an extent becomes shared, it get's re-striped at the highest raid profile (prioritizing 3-copy or higher replication over raid56) of any of the files that share the extent. This would result in some more I/O than the usual clone operation in some cases, but any other method has the potential to silently reduce the degree of data safety for a given file.It definitely makes the process at the start of allocating a new block group much more complex: you have to walk back up through an arbitrary depth of nested subvols to find the one that's actually got a replication policy record in it. (Because after this feature is brought in, there will be lots of filesystems without per-subvol replication policies in them, and we have to have some way of dealing with those as well). With an FS default policy, you only need check the current subvol, and then fall back to the FS default if that's not found.That looks reasonable to me.These things are, I think, likely to be lightly used: I would be reasonably surprised to find more than two or possibly three storage policies in use on any given system with a sane sysadmin.Agreed. At the moment I'm thinking about all the configuration possibilites we want to give to the users. Eg. the inheritance can be configurable on the property level. The usecase: the toplevel has compression enabled but I don't want any new subvolume share this property automatically. (The blockgroup type is probably a bad example for configurable inheritance as it would not work for shared extents if the type is different.)
Attachment:
smime.p7s
Description: S/MIME Cryptographic Signature
