On 09/19/2016 03:52 PM, Christoph Anton Mitterer wrote:
On Mon, 2016-09-19 at 13:18 -0400, Austin S. Hemmelgarn wrote:
- even mounting a fs ro, may cause it to be changed
This would go to the UseCases
My same argument about the UUID issues applies here, just without
the
security aspect.
I personally could agree to have that "just" in the usecases.
That a fs my be changed even though it's mounted ro is not unique to
btrfs.... and the need for not having that happen goes probably rather
into data-forensics and rescue use cases.
IMO there's rather a general problem, namely that the different
filesystems don't provide a mount option that implies every other mount
options currently needed to get an actual "hard ro", i.e. one where the
device is never written to.
Qu was about to add such option when nologreplay was added, but IIRC he
got some resistance by linux-fs, who probably didn't care enough
whether the end-user can easily do such "hard ro" mount ;)
That's in the blockdev command (blockdev --setro /dev/xxx).
We actually try to maintain the established norms where it doesn't
conflict with the btrfs use cases. This is one of them ;)
-chris
--
To unsubscribe from this list: send the line "unsubscribe linux-btrfs" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
