On 8/5/09, leon zadorin wrote:
> On 8/5/09, Otto Moerbeek wrote:
>> The big difference is that a disklabel is relatively easy to
>> recover (the system even makes backups for your automatically). The
>> label is in a fixed spot, and there is a tool (disklabel(8)) to
>> rewrite it.
>
> Automatic b
On 8/5/09, Otto Moerbeek wrote:
> The big difference is that a disklabel is relatively easy to
> recover (the system even makes backups for your automatically). The
> label is in a fixed spot, and there is a tool (disklabel(8)) to
> rewrite it.
Automatic backup sounds nice. Although I suppose I c
On Wed, Aug 05, 2009 at 05:16:10PM +1000, leon zadorin wrote:
> On 8/5/09, leon zadorin wrote:
> > On 8/5/09, Otto Moerbeek wrote:
> >> I don't have time now to test your scenario. But I'm pretty sure your
> >> test will fail the moment non-default fragment or blocksizes are used
> >> in such a
On 8/5/09, leon zadorin wrote:
> In the examples of *corrupted* superblocks though there appears not to
> be much difference -- i.e. "disk sectors hosting the starting
> superblock being corrupted" vs "disk sectors hosting disklabel being
> corrupted": both are irrecoverable (?)
Should probably p
On 8/5/09, leon zadorin wrote:
> On 8/5/09, Otto Moerbeek wrote:
>> I don't have time now to test your scenario. But I'm pretty sure your
>> test will fail the moment non-default fragment or blocksizes are used
>> in such a way that the first alternate superblock does not end up at
>> it's usual
On 8/5/09, Otto Moerbeek wrote:
> On Wed, Aug 05, 2009 at 02:17:14AM +1000, leon zadorin wrote:
>
>> On 8/4/09, Otto Moerbeek wrote:
>> > On Tue, Jul 28, 2009 at 03:26:08PM +1000, leon zadorin wrote:
>> >
>> >> That's all I am saying. Feel free to ignore or make "blah blah blah"
>> >> noises :-)
On 8/5/09, Ted Unangst wrote:
> On Tue, Aug 4, 2009 at 12:17 PM, leon zadorin wrote:
>> Perhaps, *indeed*, I am not looking in *all* of the right places and
>> so in the meantime (as I will be looking more into the rest of the
>> fsck_ffs code when I get more time), I thought I'd hack up a quick
>
On Wed, Aug 05, 2009 at 02:17:14AM +1000, leon zadorin wrote:
> On 8/4/09, Otto Moerbeek wrote:
> > On Tue, Jul 28, 2009 at 03:26:08PM +1000, leon zadorin wrote:
> >
> >> That's all I am saying. Feel free to ignore or make "blah blah blah"
> >> noises :-)
> >>
> >> So now we can, perhaps, get bac
On Tue, Aug 4, 2009 at 12:17 PM, leon zadorin wrote:
> Perhaps, *indeed*, I am not looking in *all* of the right places and
> so in the meantime (as I will be looking more into the rest of the
> fsck_ffs code when I get more time), I thought I'd hack up a quick
> empirical scenario: svnd an image,
On 8/4/09, Otto Moerbeek wrote:
> On Tue, Jul 28, 2009 at 03:26:08PM +1000, leon zadorin wrote:
>
>> That's all I am saying. Feel free to ignore or make "blah blah blah"
>> noises :-)
>>
>> So now we can, perhaps, get back (if at all) to the man pages and what
>> they are implying wrt original que
On Tue, Jul 28, 2009 at 03:26:08PM +1000, leon zadorin wrote:
> That's all I am saying. Feel free to ignore or make "blah blah blah" noises
> :-)
>
> So now we can, perhaps, get back (if at all) to the man pages and what
> they are implying wrt original question.
>
> Leon.
I'm just back from v
I tried reading this but after the 3rd empty sentence my brain stopped.
You are just way too awesome for me to be able to cope.
Now if you'll excuse I am going to write some code instead of having
meaningless debates.
On 7/28/09, leon zadorin wrote:
> How you choose to represent the behavior's definition is irrelevant
> (code or words, on paper or on screen).
>
> I am, at this stage of conversation (if one can call it such), noting
> the difference (in my opinion) between implementation and definition
> -- and
leon zadorin wrote:
who are obviously much more talented and accomplished than i. it is my
life's work to make mountains out of minutae, bear witness to my
steaming pile of awesomeness.>
stop posting this on tech@ plz, it's *too* awesome.
On 7/28/09, Marco Peereboom wrote:
>> Perhaps, but I am not going to enter any 'p*issing contests' of who's
>> got whose name where (besides, I am not implying to be an uber-coder,
>> but I do reserve the right to express my opinion wrt matter at hand).
>> I would like to retain the concentration
> Perhaps, but I am not going to enter any 'p*issing contests' of who's
> got whose name where (besides, I am not implying to be an uber-coder,
> but I do reserve the right to express my opinion wrt matter at hand).
> I would like to retain the concentration on the matter discussed.
Your opinion i
please stop jargonizing in an attempt to make yourself sound smart, it
is painfully academic. your behavior reminds me of grad school misfits i
have worked with who are convinced that being a pompous jerk is
equivalent to being successful.
have some manners and don't send your retarded message
On 7/27/09, Marco Peereboom wrote:
>> :-) :-) :-) relax, take a pill -- no need to get emotional.
>>
>> besides I don't think we are seeing things that much differently. I
>> didn't say you were making mistakes, but if you make krap-inviting
>> statements like "the source code *defines* the behavi
On 7/27/09, Theo de Raadt wrote:
>> On 7/27/09, Theo de Raadt wrote:
>> >> On 7/27/09, Theo de Raadt wrote:
>> >> >> Sounds a little nonsensical to me.
>> >> >>
>> >> >> 1) for example, it would make no sense to 'shrink' the size of
>> >> >> conceptual 'whole disk' (esp. if such represents the e
> :-) :-) :-) relax, take a pill -- no need to get emotional.
>
> besides I don't think we are seeing things that much differently. I
> didn't say you were making mistakes, but if you make krap-inviting
> statements like "the source code *defines* the behavior" then expect
> the likewise, albeit n
> On 7/27/09, Theo de Raadt wrote:
> >> On 7/27/09, Theo de Raadt wrote:
> >> >> Sounds a little nonsensical to me.
> >> >>
> >> >> 1) for example, it would make no sense to 'shrink' the size of
> >> >> conceptual 'whole disk' (esp. if such represents the entire *physical*
> >> >> disk as per man
On 7/27/09, Theo de Raadt wrote:
>> On 7/27/09, Theo de Raadt wrote:
>> >> Sounds a little nonsensical to me.
>> >>
>> >> 1) for example, it would make no sense to 'shrink' the size of
>> >> conceptual 'whole disk' (esp. if such represents the entire *physical*
>> >> disk as per man pages) to be
On 7/27/09, Theo de Raadt wrote:
>> Sounds a little nonsensical to me.
>>
>> 1) for example, it would make no sense to 'shrink' the size of
>> conceptual 'whole disk' (esp. if such represents the entire *physical*
>> disk as per man pages) to be less than other partitions -- so
>> '*arbitrary* cha
> On 7/27/09, Theo de Raadt wrote:
> >> Sounds a little nonsensical to me.
> >>
> >> 1) for example, it would make no sense to 'shrink' the size of
> >> conceptual 'whole disk' (esp. if such represents the entire *physical*
> >> disk as per man pages) to be less than other partitions -- so
> >> '*
On 7/27/09, Theo de Raadt wrote:
>> I'd say. Anywhere does it say this? My understanding was that 'c'
>> partition depicts the entire device. If this is correct, than it's not
>> even close to describing it as 'freely changing' it's semantics as per
>> kernel's mood. Artistic perhaps, but precise.
> Sounds a little nonsensical to me.
>
> 1) for example, it would make no sense to 'shrink' the size of
> conceptual 'whole disk' (esp. if such represents the entire *physical*
> disk as per man pages) to be less than other partitions -- so
> '*arbitrary* changing its [disk's] limits' is an over-g
> I'd say. Anywhere does it say this? My understanding was that 'c'
> partition depicts the entire device. If this is correct, than it's not
> even close to describing it as 'freely changing' it's semantics as per
> kernel's mood. Artistic perhaps, but precise... not.
hey, feel free to believe wha
On 7/27/09, Kenneth R Westerback wrote:
> On Mon, Jul 27, 2009 at 11:11:21AM +1000, leon zadorin wrote:
>> On 7/27/09, Kenneth R Westerback wrote:
>> > On Sun, Jul 26, 2009 at 04:44:45AM +1100, leon zadorin wrote:
>> >> Man page for mount_vnd states:
>> >> "
>> >> The `c' partition of a vnd image
On Mon, Jul 27, 2009 at 11:11:21AM +1000, leon zadorin wrote:
> On 7/27/09, Kenneth R Westerback wrote:
> > On Sun, Jul 26, 2009 at 04:44:45AM +1100, leon zadorin wrote:
> >> Man page for mount_vnd states:
> >> "
> >> The `c' partition of a vnd image should not be used. When a superblock
> >>
On 7/27/09, Kenneth R Westerback wrote:
> On Sun, Jul 26, 2009 at 04:44:45AM +1100, leon zadorin wrote:
>> Man page for mount_vnd states:
>> "
>> The `c' partition of a vnd image should not be used. When a superblock
>> becomes damaged, fsck_ffs(8) needs information contained in the
>> diskl
On Sun, Jul 26, 2009 at 04:44:45AM +1100, leon zadorin wrote:
> Man page for mount_vnd states:
> "
> The `c' partition of a vnd image should not be used. When a superblock
> becomes damaged, fsck_ffs(8) needs information contained in the disklabel
> to determine the location of alternate
On Sun, Jul 26, 2009 at 04:44:45AM +1100, leon zadorin wrote:
> Man page for mount_vnd states:
> "
> The `c' partition of a vnd image should not be used. When a superblock
> becomes damaged, fsck_ffs(8) needs information contained in the disklabel
> to determine the location of alternate
Man page for mount_vnd states:
"
The `c' partition of a vnd image should not be used. When a superblock
becomes damaged, fsck_ffs(8) needs information contained in the disklabel
to determine the location of alternate superblocks. This information is
not available when directly usin
33 matches
Mail list logo
