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 e
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 no
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 {
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
> sh
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
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 e
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 == _
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 linux
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;
On Mon, 2007-07-23 10:15:21 +0200, Rene Herman <[EMAIL PROTECTED]> wrote:
> /*
> * Public Domain 2007, Rene Herman
> */
>
> #define _LARGEFILE64_SOURCE
>
> #include
> #include
> #include
> #include
>
> #include
> #include
> #include
> #include
> #include
>
> enum {
> DOS_EXTEND
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
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 t
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 subsyste
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
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
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 chang
On 07/20/2007 06:06 PM, Theodore Tso wrote:
It wouldn't be that hard to put a backup partition table at the beginning
of an ext2/3 filesystem. No one is currently using the space between
offset 512 and 1023 bytes, and it would be an easy place to stash a
backup copy of the partition table. We
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. Ju
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 y
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 co
On 20 Jul 2007, at 12:29, Al Boldi wrote:
Anton Altaparmakov wrote:
parted and its derivatives are pile of crap... They cause corruption
to totally healthy systems at the best of times. Don't go near them.
Use TestDisk (http://www.cgsecurity.org/wiki/TestDisk) and be happy.
(-:
This one rea
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'.
MfG, JBG
--
Jan-Benedict Glaw [EMAIL PROTECTED] +
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
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 proba
Jan Engelhardt wrote:
> On Jul 20 2007 07:35, Willy Tarreau wrote:
> >On Fri, Jul 20, 2007 at 08:13:03AM +0300, 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 leas
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
26 matches
Mail list logo
