Re: [RFH] Partition table recovery

2007-07-23 Thread Rene Herman
On 07/22/2007 06:28 PM, Theodore Tso wrote: [ Al -- don't drop CCs please ] Well, let's think about this a bit. What are the requirements? 1) The partition manager should be able explicitly request that a new backup of the partition tables be stashed in each filesystem that has room for such

Re: [RFH] Partition table recovery

2007-07-23 Thread Jan-Benedict Glaw
On Mon, 2007-07-23 10:15:21 +0200, Rene Herman [EMAIL PROTECTED] wrote: /* * Public Domain 2007, Rene Herman */ #define _LARGEFILE64_SOURCE #include stdlib.h #include stdio.h #include stdint.h #include string.h #include sys/types.h #include sys/stat.h #include sys/ioctl.h

Re: [RFH] Partition table recovery

2007-07-23 Thread Rene Herman
On 07/23/2007 10:41 AM, Jan-Benedict Glaw wrote: As multibyte on-disk variables, these will need LE/BE conversion. Indeed, thanks -- has been updated in the version that is attached. Also fixes a bug that snuck in (failed to add offset to entry-start). struct entry { uint8_t flags;

Re: [RFH] Partition table recovery

2007-07-23 Thread Rene Herman
On 07/23/2007 12:54 PM, Rene Herman wrote: static inline uint32_t le_32(uint32_t n) { #ifdef __LITTLE_ENDIAN return n; #else return bswap_32(n); #endif } #if __BYTE_ORDER == __LITTLE_ENDIAN, that is. sigh. Rene. - To unsubscribe from this list: send the line unsubscribe

Re: [RFH] Partition table recovery

2007-07-23 Thread Jan-Benedict Glaw
On Mon, 2007-07-23 14:39:11 +0200, Rene Herman [EMAIL PROTECTED] wrote: On 07/23/2007 12:54 PM, Rene Herman wrote: static inline uint32_t le_32(uint32_t n) { #ifdef __LITTLE_ENDIAN return n; #else return bswap_32(n); #endif } #if __BYTE_ORDER == __LITTLE_ENDIAN, that

Re: [RFH] Partition table recovery

2007-07-23 Thread Rene Herman
On 07/23/2007 03:15 PM, Jan-Benedict Glaw wrote: static inline uint32_t le_32(uint32_t n) { #ifdef __LITTLE_ENDIAN return n; #else return bswap_32(n); #endif } #if __BYTE_ORDER == __LITTLE_ENDIAN, that is. sigh. Don't forget PDP11 byteorder :-) How could I? It cracks me up

Re: [RFH] Partition table recovery

2007-07-23 Thread Theodore Tso
On Mon, Jul 23, 2007 at 09:34:25AM +0200, Rene Herman wrote: The most profound issue is _what_ to save. I for example don't cylinder align my partitions (I hate wasting disk just to appease broken software) meaning that not all my end_head/sector values are consistent even at the best of

Re: [RFH] Partition table recovery

2007-07-23 Thread Theodore Tso
On Mon, Jul 23, 2007 at 10:15:21AM +0200, Rene Herman wrote: On an integrated system like this, do you consider it acceptable to only do the MS-DOS partitions and not the other types that may be present _inside_ those partitions? (MINIX subpartitions, BSD slices, ...). I believe those

Re: [RFH] Partition table recovery

2007-07-23 Thread Bill Davidsen
Rene Herman wrote: On 07/23/2007 10:41 AM, Jan-Benedict Glaw wrote: As multibyte on-disk variables, these will need LE/BE conversion. Indeed, thanks -- has been updated in the version that is attached. Also fixes a bug that snuck in (failed to add offset to entry-start). struct entry {

Re: [RFH] Partition table recovery

2007-07-23 Thread Rene Herman
On 07/23/2007 03:48 PM, Theodore Tso wrote: On Mon, Jul 23, 2007 at 09:34:25AM +0200, Rene Herman wrote: That's not quite correct. Logicals have a start field relative to the encompassing extended (ie, for me always 1, for others often always 63) and the encompassing extended are relative

Re: [RFH] Partition table recovery

2007-07-23 Thread 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

Re: [RFH] Partition table recovery

2007-07-22 Thread Rene Herman
On 07/22/2007 03:11 AM, Theodore Tso wrote: This is a problem. Today the CHS fields in the partition entries don't mean much of anything anymore and Linux happily ignores them but DOS and (hence) Windows 9x do not. From time to time I still have the Windows 98 install that's sitting in a corner

Re: [RFH] Partition table recovery

2007-07-22 Thread Theodore Tso
On Sun, Jul 22, 2007 at 07:10:31AM +0300, Al Boldi wrote: Sounds great, but it may be advisable to hook this into the partition modification routines instead of mkfs/fsck. Which would mean that the partition manager could ask the kernel to instruct its fs subsystem to update the backup

Re: [RFH] Partition table recovery

2007-07-22 Thread Al Boldi
Theodore Tso wrote: On Sun, Jul 22, 2007 at 07:10:31AM +0300, Al Boldi wrote: Sounds great, but it may be advisable to hook this into the partition modification routines instead of mkfs/fsck. Which would mean that the partition manager could ask the kernel to instruct its fs subsystem to

Re: [RFH] Partition table recovery

2007-07-22 Thread Indan Zupancic
On Sun, July 22, 2007 18:28, Theodore Tso wrote: On Sun, Jul 22, 2007 at 07:10:31AM +0300, Al Boldi wrote: Sounds great, but it may be advisable to hook this into the partition modification routines instead of mkfs/fsck. Which would mean that the partition manager could ask the kernel to

Re: [RFH] Partition table recovery

2007-07-21 Thread Al Boldi
Theodore Tso wrote: On Sat, Jul 21, 2007 at 07:54:14PM +0200, Rene Herman wrote: sfdisk -d already works most of the time. Not as a verbatim tool (I actually semi-frequently use a sfdisk -d /dev/hda | sfdisk invocation as a way to _rewrite_ the CHS fields to other values after changing

Re: [RFH] Partition table recovery

2007-07-20 Thread Al Boldi
Jeffrey V. Merkey wrote: Al Boldi wrote: As always, a good friend of mine managed to scratch my partion table by cat'ing /dev/full into /dev/sda. I was able to push him out of the way, but at least the first 100MB are gone. I can probably live without the first partion, but there are many

Re: [RFH] Partition table recovery

2007-07-20 Thread Al Boldi
Dave Young wrote: On 7/20/07, Al Boldi [EMAIL PROTECTED] wrote: As always, a good friend of mine managed to scratch my partion table by cat'ing /dev/full into /dev/sda. I was able to push him out of the way, but /dev/null ? at least the first 100MB are gone. I can probably live

Re: [RFH] Partition table recovery

2007-07-20 Thread Al Boldi
James Lamanna wrote: On 7/19/07, Al Boldi [EMAIL PROTECTED] wrote: As always, a good friend of mine managed to scratch my partion table by cat'ing /dev/full into /dev/sda. I was able to push him out of the way, but at least the first 100MB are gone. I can probably live without the first

Re: [RFH] Partition table recovery

2007-07-20 Thread Al Boldi
Jan-Benedict Glaw wrote: On Fri, 2007-07-20 14:29:34 +0300, Al Boldi [EMAIL PROTECTED] wrote: But, I want something much more automated. And the partition table backup per partition entry isn't really a bad idea. That's called `gpart'. Oh, gpart is great, but if we had a backup copy of

Re: [RFH] Partition table recovery

2007-07-20 Thread Rene Herman
On 07/20/2007 02:22 PM, Al Boldi wrote: Oh, gpart is great, but if we had a backup copy of the partition table on every partition location on disk, then this backup copy could easily be reused to reconstruct the original partition table without further searching. As long as you don't reboot

Re: [RFH] Partition table recovery

2007-07-20 Thread Theodore Tso
On Fri, Jul 20, 2007 at 03:22:17PM +0300, Al Boldi wrote: Oh, gpart is great, but if we had a backup copy of the partition table on every partition location on disk, then this backup copy could easily be reused to reconstruct the original partition table without further searching. Just