Re: Mounting(multiply)? Options(stored)? Options(barriers)?

[Robert White <rwhite@pobox.com>]

On 10/23/2014 07:25 PM, Duncan wrote:
> See the discussion above.  As for whether conflicting options error out,
> get ignored, or update the whole filesystem, there has been some
> discussion on the list but IDR the conclusion as it doesn't pertain to me
> since I don't use subvolumes like that, preferring fully independent
> filesystems on their own partitions, instead.  (If the filesystem
> metadata gets corrupted, it can easily mean the loss of all data on it.
> Subvolumes provide little if any protection in that regard.  I *STRONGLY*
> prefer not to put all my data eggs in one filesystem basket, in case its
> bottom falls out.)  I believe in some cases either the conflicting mount
> will error out or it'll mount but ignore the conflicts (IOW, it shouldn't
> arbitrarily rewrite the option for the entire filesystem, that's what
> remount is for!), but don't know if it actually works that way for
> everything yet.  Either watch for a response from someone with practical
> knowledge of the situation, or do your own testing, before you depend on
> it.

Ouch, I abandoned multiple hard partitions on any one spindle a long, 
long time ago. The failure modes likely to occur just don't justify the 
restrictions and hassle. Let alone the competitive file-system 
scheduling that can eat your system performance with a box of wine.

I've been in this mess since Unix System 3 release 4. The mythology of 
the partitioned disk is deep and horrible. Ever since they stopped the 
implementation of pipes as anonymous files on the root partition, most 
of the reasoning ends up backward.

Soft failures are likely to spray the damage all over all the 
filesystems by type, and a disk failure isn't going to obey the 
partition boundaries.

Better the efficiency of the whole disk file-systems and a decent backup 
plan.

Just my opinion.