Am 08.02.2016 um 20:49 schrieb f-dm-c@xxxxxxxxxxxxx:
> Date: Mon, 8 Feb 2016 17:48:22 +0100
> From: Arno Wagner <arno@xxxxxxxxxxx>
> I like the end, because it is clear and far away. It is also what
> md-RAID for superblock 0.90 does.
Doesn't that increase the chances of mdraid 0.90 stepping on your own
"far away" header?
If mdadm doesn't recognize the presence of that header, yes it would
potentially trash that backup header (and possibly some data right at
the end of the device), That would not be desastrous though, as the
primary header would still be valid. Same holds true the other way
round. Anyway, this is a generic problem, i.e. a new filesystem
signature at the beginning would be trashed by mdadm with 1.1 or 1.2
metadata and a whole bunch of other tools. That's why most filesystems
do have redundancy in their superblocks and parts of their
metadata-structures, I guess.
> Non-redudancy during resize is not an issue, as anybody sane will
> only resize with a header-backup done before. Insane people will
> manage to screw up anyways, nothing we can do about that. Resize
> is a dangerous operation, no way around that. We can prevent
> people from hosing their LUKS container when creating filesysems
> on it though, or partition sectors or the like.
As long as whatever redundancy gets added doesn't eliminate the
ability to do an -online- grow, I don't care. It's when people
start saying "disallow online resize -because of- the redudancy"
that I start questioning the wisdom of the entire concept, and
that's why I spoke up at all.
(Note that I don't care so much re online -shrink-, because ext4
at least can't do that either.)
Is there any filesystem right now, that does support online shrinking?
Most bits in the blocklayer support (online) shrinking though.
_______________________________________________
dm-crypt mailing list
dm-crypt@xxxxxxxx
http://www.saout.de/mailman/listinfo/dm-crypt
