> Sounds a little nonsensical to me. > > 1) for example, it would make no sense to 'shrink' the size of > conceptual 'whole disk' (esp. if such represents the entire *physical* > disk as per man pages) to be less than other partitions -- so > '*arbitrary* changing its [disk's] limits' is an over-generalization > in my opinion. > > 2) w.r.t. forward-compatibility, one cannot make any suppositions for > system's (kernel or userland) behavior in future versions/releases for > practically anything (e.g. the key-generating hash in vnconfig may not > be guaranteed to forever remain the same; the format of system calls > may change/evolve, disklabel format may/may-not change, sector-size > may become editable, etc.)... and I am certainly not looking this far > into the future (i.e. namely and most-likely I am considering the > behavior wrt current kernel w/o such being upgraded continuously). In > other words, I am perfectly happy to accept the failed 'mount/fsck' > attempts when/if differently-behaving kernel is being deployed.
The source code defines the behaviour. Your words don't.