Hi,
Man pages for vnconfig state that one of the useful things for "vnd"
devices (not svnd ones) is to make them be used for swap.
Given that vnconfig associates a vnd device with a regular file -- the
above comments reduce to allowing one to use regular file as a swap
space... only... why would
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
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(
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:
>> &
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.
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:
>> 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:
>> 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
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/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
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
On 7/29/09, Atle Kristensen wrote:
>> > I am, at this stage of conversation (if one can call it such), noting
>> > the difference (in my opinion) between implementation and definition
>
> There is ALWAYS a difference while dealing with two "languages":
> code <-> specification/documentation.
Sur
On 7/29/09, leon zadorin wrote:
> On 7/29/09, Atle Kristensen wrote:
>
>>> > I am, at this stage of conversation (if one can call it such), noting
>>> > the difference (in my opinion) between implementation and definition
>>
>> There is ALWAYS a di
On 7/29/09, Rod Whitworth wrote:
> On Wed, 29 Jul 2009 14:44:55 +1000, leon zadorin wrote:
>
> Heaps of crap.
> --
:-) :-) :-) so many people who are so ready to express their logical
and useful comments.
>
> You should have read http://www.openbsd.org/mail.html
> where
On 7/29/09, Bret S. Lambert wrote:
> On Wed, Jul 29, 2009 at 04:01:53PM +1000, leon zadorin wrote:
>> On 7/29/09, Rod Whitworth wrote:
>> > On Wed, 29 Jul 2009 14:44:55 +1000, leon zadorin wrote:
>> >
>> > Heaps of crap.
>> > --
>>
>> :-)
On 7/29/09, Alexander Hall wrote:
>> ps people do need to relax and take it easy indeed (emotionally that is)
>> :-)
>
> People dislike having to dig through tons of crap like this in their
> inbox. You are just fucking annoying and if you keep this up you should
> not expect ever getting any help
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 pag
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 though
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
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 d
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 ir
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 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
>>
23 matches
Mail list logo
