Re: [RFH] Partition table recovery

[Rene Herman]

On 07/23/2007 03:58 PM, Theodore Tso wrote:

> Well, I'm considering this to be a MBR backup scheme, so Minix and BSD 
> slices are legacy systems which are out of scope.  If they are busted in
> the same way as MBR in terms of not having redundant backups of critical
> data, when they have a lot fewer excuses that MBR, and they can address
> that issue in their own way.  The number of Linux users that also have
> Minix and BSD partitions are a vanishingly small number in any case.

I'd in fact expect quite a few people to have a FreeBSD partition around. 
And MINIX if they are in university and in an operating systems course...

But "they should take whatever precautions they want themselves" is a valid 
argument.

[ blkid ]

> Yeah, good point, I'd have to add that support into blkid.  It's been
> on my todo list, but I just haven't gotten around to it yet.

I'll for now stop updating the partbackup thingy as posted. Given that Linux 
 only follows the first extended in the list of extendeds (which sort of 
destroys the nice recursion anyway) it might want to be iterative instead of 
recursive if the thing has a future -- not very important though.

> My concern of sysfs is that #1, it won't work on older kernels since
> you would need to add new fields to backup what we want,

I'd be okay with that.

> and #2, I'm still fundamentally distrustful of sysfs because there isn't
> a bright line between what is an exported interface that will never
> change, and something which is considered an "internal implementation
> detail" that can change whenever some kernel hacker feels like it.  (Or
> when some kernel hacker is careless...)  So as far as I'm concerned sysfs
> is a terrible, TERRIBLE way to export a published interface where we 
> promise stability to userspace.

Oh come on, that's going overboard a bit, it's not all _that_ bad! Finding 
say "sda" will be possible without breaking too many times. Admittedly, the 
kernel's partittion scanning order is also not likely to change as it would 
certainly break userspace, but code duplication, with the possiblity of bugs 
slipping in at least userspace-ways (considering the kernel the reference no 
matter what it does) is a concern. Somewhat. A little.

> So I'd just as soon do this in userspace; after all, the entire partition
> manager (and there are multiple ones; fdisk, sfdisk, gpart, etc.) all in
> userspace, and that needs to be in synch with the kernel partition
> reading code anyway.  So one more userspace implementation is in my mind
> much cleaner than trying to push the needed functionality into sysfs, and
> then hoping against hope that it doesn't accidentally change in the
> future.

* rene envisions /lib/libpart.so...

Not to mention my Grand Visions of a totally new Linux native partitioning 
scheme probably modelled after BSD slices (as also mentioned in a previous 
message just now). Or perhaps LVM already fills that role comfortably. It's 
certainly what I hear everyone talking about these days.

Rene.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/