Bug 864638

This came up in IRC discussion prior to filing bug 864611.

In normal production situations with large volumes, especially if they are distributed, gluster bricks will live on filesystems that are separate from the root filesystem.

Allowing gluster to operate on the root filesystem in a situation like the above is a major problem, because typically the root filesystem will be very small (gigabytes) but the bricks will be larger (terabytes).  Any "didn't mean to type that directory" or "disk didn't get mounted" mistake that points a brick at a location on the root filesystem will quickly run out of disk space and potentially cause fatal problems.

In testbeds or production situations that don't require a lot of complexity, you might actually want your brick data to live on your root filesystem.

I would propose two things.  When creating a volume with brick paths that are on the root filesystem, give the user a warning to that effect, optionally displaying an "are you sure?" prompt unless script mode is enabled.  When the user (or glusterd itself on reboot) then attempts to *start* the volume, that operation should fail, unless a volume property is set to allow it.  My current suggestion for the property name would be allow.rootfs.  The failure message should probably mention the property name.

This new feature would have to be able to seamlessly handle upgrades from previous versions where bricks do exist on the root filesystem.

If (and only if) you can reliably detect that 1) you're doing an upgrade (volume was last handled by a previous version) AND 2) whether all of the bricks are on their own filesystems, you can automatically set the new parameter to false or true according to what you detect.  If these detections are not possible, you would have to always assume you're in an upgrade situation, so if the property is missing and the volume was previously started, you have to set it to true.

The documentation would need to be updated in several locations.