Safety of GEOM metadata

T

Twister

Hello!

I have some suggestions to FreeBSD developers about GEOM. Please tell me where I can send my suggestions?
I give it here to discuss it before sending to developers.

Geom saves it's metadata in last sector. It is dangerous.
Last sector is used for storing some information by GPT for example. So if you mirror disks (gmirror) with GPT partitioning - GPT and gmirror can rewrite each other's data. It's dangerous.
In other case - if you mirror partitions on disks - there is a danger too. gmirror metadata is stored in last sector of partition. Does filesystem know about it? What will happend if geom's metadata will be rewrited by some file data?

My suggestion is:
geom must search its metadata in last sector and previous sector (metadata from previous sector can be used if metadata in last sector is corrupted),
and there must be utility to create special file on filesystem, file must points to metadata - it must lay on sectors with metadata. This file can have some special attributes - immutable, nochg and so on.

What do you think about it?
 
Assume someone new to FreeBSD and to partitioning also. Maybe they would benefit from a complex flowchart upon which could be sited almost all known scenarios, where following the lines from "present situation" to "end result" would preclude the dangers... as well
as serving as a guide for which command to use. (I'm not competent enough to begin to formulate one...)
 
All this is not much of a problem, as GPT is a geom class as well.
Geom describes, for a range of sectors, how to deal with them. So, to pick up your example of mirroring, you have 2 discs of, let's say, 100 blocks, and call it ada0 and another one like it called ada1.

These are [0..99], and #99 holds the meta data for the gmirror class.
Because the last sector is from gmirror, gmirror claims ownership of the drives and removes ada0 and ada1 from the available providers. It then creates a new provider which is the mirror of ada0/ada1, but only has blocks [0..98]. This means the last block us not reachable for anyone dealing with the mirror device, the last block a file system can see on the mirror is #98. This one may also be geom metadata. The process would repeat then, giving you a new provider which again is one block shorter than before, but with a new driver attached to it. Maybe geli is used to encrypt the mirror, then we would have :

Code: 
ada0       [0..97 98 99]
  +
ada1       [0..97 98 99]
  = 
gmirror    [0..97 98]
(+geli)
  =
mirror.eli [0..97]

The beauty is that all these containers start at 0, so all I/O may be done without adding a constant any time a geom layer is traversed. Only the maximum needs to be taken into account, and usually that is done at file system creation which is done once, not at each I/O to that file system.

So all this is a) already taken care of and b) pretty straight forward once you explain it using russian dolls.
 
GPT backup partition tables can conflict with GEOM metadata. Where that is a problem is attempting to use gmirror(8) to mirror two drives. The easiest solution right now is to just use MBR partitioning, which has no data at the end of the drive. GPT mirrors can be made if you mirror the individual partitions.
 
It does in a way. Anything that is not aware of the mirror (boot loaders, other operating systems, rescue tools that do not know about GEOM) will then look for the backup partition table on the last LBA sector of the disk and can't find it and will claim that the partition table is corrupt. That's because it has been written on the second last LBA sector. The mirrored device was one sector smaller (from the end) than the physical disk when the GPT partitioning was created.
 
You must log in or register to reply here.
Back
Top