vnconfig vs swapctl for regular files
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 one do all of this when swapctl/swapon accept regular file as arg anyway? In other words what are the advantages to using vnconfig for swapping as opposed to just calling swapctl/swapon directly on a regular file? Moreover, fstab also takes regular file for swap partitions just fine and subsequent (implicit) call to swapon also appears to work just fine... Does it have to do, may be, with earlier versions of swapctl not working with regular files... or some other historical differences in the early days? Also, if there is no distinct advantage of using vnconfig's vnd for swap (vs swapctl)... what other uses are there for explicit '/dev/vnd' (not 'svnd') devices? Kind regards Leon.
man pages conflict or clarification for mount_vnd, newfs and man 5 disklabel
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 using the `c' partition, so checking the file system image will fail. " Also, the man page for newfs states: " Before running newfs or mount_mfs, the disk must be labeled using disklabel(8). newfs builds a file system on the specified special de- vice, basing its defaults on the information in the disk label. " But... the man 5 disklabel states: " Note that when a disk has no real BSD disklabel the kernel creates a de- fault label so that the disk can be used. " And indeed, it would appear (or may be my brain is getting sleepy) that, running newfs on a device (such as svnd0c or vnd0c) which has no disklabel installed explicitly does work ok... ... now -- if, as man page for mount_vnd states, fsck_ffs needs disklabel info when superblock is damaged -- why would it have any trouble getting the default label that kernel creates for the "disk" automatically as per man 5 disklabel quote above (the very same info, I presume that newfs uses when initializing the fs initially on an image with no explicit label)? For example, wrt alternate superblock issues during fskc, the man page for newfs says: " -S sector-size The size of a sector in bytes (almost never anything but 512). Changing this is useful only when using newfs to build a file system whose raw image will eventually be used on a different type of disk than the one on which it is initially created (for example on a write-once disk). Note that chang- ing this from its default will make it impossible for fsck(8) to find the alternate superblocks if the standard superblock is lost. " Now, if the default disklabel (created by kernel, on the fly so to speak) provides info for the sector size (which is used by newfs during initializing, and by fsck when checking/restoring/fixing, the fs) then why would it still be bad to use the "c" partition of svnd/vnd? Kind regards Leon.
Re: man pages conflict or clarification for mount_vnd, newfs and man 5 disklabel
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 >> disklabel >> to determine the location of alternate superblocks. This information >> is >> not available when directly using the `c' partition, so checking the >> file >> system image will fail. >> " >> >> Also, the man page for newfs states: >> " >> Before running newfs or mount_mfs, the disk must be labeled using >> disklabel(8). newfs builds a file system on the specified special >> de- >> vice, basing its defaults on the information in the disk label. >> " >> >> But... the man 5 disklabel states: >> " >> Note that when a disk has no real BSD disklabel the kernel creates a de- >> fault label so that the disk can be used. >> " >> >> And indeed, it would appear (or may be my brain is getting sleepy) >> that, running newfs on a device (such as svnd0c or vnd0c) which has no >> disklabel installed explicitly does work ok... >> ... now -- if, as man page for mount_vnd states, fsck_ffs needs >> disklabel info when superblock is damaged -- why would it have any >> trouble getting the default label that kernel creates for the "disk" >> automatically as per man 5 disklabel quote above (the very same info, >> I presume that newfs uses when initializing the fs initially on an >> image with no explicit label)? >> >> For example, wrt alternate superblock issues during fskc, the man page >> for newfs says: >> " >> -S sector-size >> The size of a sector in bytes (almost never anything but >> 512). Changing this is useful only when using newfs to >> build >> a file system whose raw image will eventually be used on >> a >> different type of disk than the one on which it is >> initially >> created (for example on a write-once disk). Note that >> chang- >> ing this from its default will make it impossible for >> fsck(8) >> to find the alternate superblocks if the standard >> superblock >> is lost. >> " >> >> Now, if the default disklabel (created by kernel, on the fly so to >> speak) provides info for the sector size (which is used by newfs >> during initializing, and by fsck when checking/restoring/fixing, the >> fs) then why would it still be bad to use the "c" partition of >> svnd/vnd? >> >> Kind regards >> Leon. > > 'c' is a special partition that the kernel freely changes as the > mood hits it. A slight exaggeration. 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. I don't mind not using 'c' partition for any explicit filesystems, but I don't want to do so on some ritualistic, unsupported-by-explanations 'fear' but rather through explicit understanding as to why, albeit customised, examples would not work (i.e. kernel-generated default disklabel and only 1 ffs on disk image as per previous post of mine). leon.
Re: man pages conflict or clarification for mount_vnd, newfs and man 5 disklabel
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 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 using the `c' partition, so checking >> >> the >> >> file >> >> system image will fail. >> >> " >> >> >> >> Also, the man page for newfs states: >> >> " >> >> Before running newfs or mount_mfs, the disk must be labeled using >> >> disklabel(8). newfs builds a file system on the specified special >> >> de- >> >> vice, basing its defaults on the information in the disk label. >> >> " >> >> >> >> But... the man 5 disklabel states: >> >> " >> >> Note that when a disk has no real BSD disklabel the kernel creates a >> >> de- >> >> fault label so that the disk can be used. >> >> " >> >> >> >> And indeed, it would appear (or may be my brain is getting sleepy) >> >> that, running newfs on a device (such as svnd0c or vnd0c) which has no >> >> disklabel installed explicitly does work ok... >> >> ... now -- if, as man page for mount_vnd states, fsck_ffs needs >> >> disklabel info when superblock is damaged -- why would it have any >> >> trouble getting the default label that kernel creates for the "disk" >> >> automatically as per man 5 disklabel quote above (the very same info, >> >> I presume that newfs uses when initializing the fs initially on an >> >> image with no explicit label)? >> >> >> >> For example, wrt alternate superblock issues during fskc, the man page >> >> for newfs says: >> >> " >> >> -S sector-size >> >> The size of a sector in bytes (almost never anything >> >> but >> >> 512). Changing this is useful only when using newfs >> >> to >> >> build >> >> a file system whose raw image will eventually be used >> >> on >> >> a >> >> different type of disk than the one on which it is >> >> initially >> >> created (for example on a write-once disk). Note that >> >> chang- >> >> ing this from its default will make it impossible for >> >> fsck(8) >> >> to find the alternate superblocks if the standard >> >> superblock >> >> is lost. >> >> " >> >> >> >> Now, if the default disklabel (created by kernel, on the fly so to >> >> speak) provides info for the sector size (which is used by newfs >> >> during initializing, and by fsck when checking/restoring/fixing, the >> >> fs) then why would it still be bad to use the "c" partition of >> >> svnd/vnd? >> >> >> >> Kind regards >> >> Leon. >> > >> > 'c' is a special partition that the kernel freely changes as the >> > mood hits it. A slight exaggeration. >> >> 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. >> >> I don't mind not using 'c' partition for any explicit filesystems, but >> I don't want to do so on some ritualistic, unsupported-by-explanations >> 'fear' but rather through explicit understanding as to why, albeit >> customised, examples would not work (i.e. kernel-generated default >> disklabel and only 1 ffs on disk image as per previous post of mine). >> >> leon. > > 2nd paragraph of disklabel(8): > > disklabel supports 15 configurable partitions, `a' through `p', excluding > `c'. The `c' partit
Re: man pages conflict or clarification for mount_vnd, newfs and man 5 disklabel
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... not. > > hey, feel free to believe whatever you want. it's not about the belief, it's about the understanding. > >> I don't mind not using 'c' partition for any explicit filesystems, but >> I don't want to do so on some ritualistic, unsupported-by-explanations >> 'fear' but rather through explicit understanding as to why, albeit >> customised, examples would not work (i.e. kernel-generated default >> disklabel and only 1 ffs on disk image as per previous post of mine). > > yeah, looking at the code is ritualistic my comments were *not* wrt source code, they were wrt to the aforementioned *artistic* definition/explanation of c's partition and it's view wrt kernel's default disklabel creation. > Guess we should stop making it available. I guess not :-)
Re: man pages conflict or clarification for mount_vnd, newfs and man 5 disklabel
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* changing its [disk's] limits' is an over-generalization >> in my opinion. >> >> 2) w.r.t. forward-compatibility, one cannot make any suppositions for >> system's (kernel or userland) behavior in future versions/releases for >> practically anything (e.g. the key-generating hash in vnconfig may not >> be guaranteed to forever remain the same; the format of system calls >> may change/evolve, disklabel format may/may-not change, sector-size >> may become editable, etc.)... and I am certainly not looking this far >> into the future (i.e. namely and most-likely I am considering the >> behavior wrt current kernel w/o such being upgraded continuously). In >> other words, I am perfectly happy to accept the failed 'mount/fsck' >> attempts when/if differently-behaving kernel is being deployed. > > The source code defines the behaviour. > > Your words don't. > Neither do yours :-) Although, some would also say that source code is not always *defining*, but rather *implementing* the behavior (which is standardized perhaps elsewhere)... but anyway -- potato, potato :-)
Re: man pages conflict or clarification for mount_vnd, newfs and man 5 disklabel
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 less than other partitions -- so >> >> '*arbitrary* changing its [disk's] limits' is an over-generalization >> >> in my opinion. >> >> >> >> 2) w.r.t. forward-compatibility, one cannot make any suppositions for >> >> system's (kernel or userland) behavior in future versions/releases for >> >> practically anything (e.g. the key-generating hash in vnconfig may not >> >> be guaranteed to forever remain the same; the format of system calls >> >> may change/evolve, disklabel format may/may-not change, sector-size >> >> may become editable, etc.)... and I am certainly not looking this far >> >> into the future (i.e. namely and most-likely I am considering the >> >> behavior wrt current kernel w/o such being upgraded continuously). In >> >> other words, I am perfectly happy to accept the failed 'mount/fsck' >> >> attempts when/if differently-behaving kernel is being deployed. >> > >> > The source code defines the behaviour. >> > >> > Your words don't. >> > >> >> Neither do yours :-) Although, some would also say that source code is >> not always *defining*, but rather *implementing* the behavior (which >> is standardized perhaps elsewhere)... but anyway -- potato, potato :-) > > Oh cut the crap. > > krw and I have a view how it should work, and we code it. > Then the code is the behaviour. > > Perhaps we made mistakes. Perhaps they'll be changed. > > But you are just spouting bullshit. > :-) :-) :-) 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 not-that-serious, replies. Besides, the code may well be acting like implementation and definition in one place, so no need to take such a heated bait to my light replies. I'll stop now :-) chill -- I don't mean to get a flame-war started, peace dude :-)
Re: man pages conflict or clarification for mount_vnd, newfs and man 5 disklabel
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 entire >> >> >> *physical* >> >> >> disk as per man pages) to be less than other partitions -- so >> >> >> '*arbitrary* changing its [disk's] limits' is an over-generalization >> >> >> in my opinion. >> >> >> >> >> >> 2) w.r.t. forward-compatibility, one cannot make any suppositions >> >> >> for >> >> >> system's (kernel or userland) behavior in future versions/releases >> >> >> for >> >> >> practically anything (e.g. the key-generating hash in vnconfig may >> >> >> not >> >> >> be guaranteed to forever remain the same; the format of system calls >> >> >> may change/evolve, disklabel format may/may-not change, sector-size >> >> >> may become editable, etc.)... and I am certainly not looking this >> >> >> far >> >> >> into the future (i.e. namely and most-likely I am considering the >> >> >> behavior wrt current kernel w/o such being upgraded continuously). >> >> >> In >> >> >> other words, I am perfectly happy to accept the failed 'mount/fsck' >> >> >> attempts when/if differently-behaving kernel is being deployed. >> >> > >> >> > The source code defines the behaviour. >> >> > >> >> > Your words don't. >> >> > >> >> >> >> Neither do yours :-) Although, some would also say that source code is >> >> not always *defining*, but rather *implementing* the behavior (which >> >> is standardized perhaps elsewhere)... but anyway -- potato, potato :-) >> > >> > Oh cut the crap. >> > >> > krw and I have a view how it should work, and we code it. >> > Then the code is the behaviour. >> > >> > Perhaps we made mistakes. Perhaps they'll be changed. >> > >> > But you are just spouting bullshit. >> > >> >> :-) :-) :-) 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 not-that-serious, replies. >> >> Besides, the code may well be acting like implementation and >> definition in one place, so no need to take such a heated bait to my >> light replies. I'll stop now :-) >> >> >> chill -- I don't mean to get a flame-war started, peace dude :-) > > I don't know who you are, but you do nothing. What do you do? > > I don't see your name on any the source code. 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. > The source code _does_ define the behaviour. Exactly. Perhaps the > source code is wrong, but it *EXACTLY DEFINES THE BEHAVIOUR*. All I was saying that it is not always the case. For example: the code in various http client/server applications *implements* the behavior (correctly or incorrectly as it may be), but the behavior is *defined* elsewhere (e.g. a standard); similar things could be said about the code in c compiler vs the c standard et al. Sometimes this may not be the case, of course, but to categorically imply that 'code defines behavior' is not right in my opinion. On the other hand -- perhaps we differ in our understanding of the term "defines". You probably implying "defines" as in "results in a given behavior", I am implying "defines" more in terms of standardization/documentation (i.e. outline/definition of rules/behavior). Either way -- this only reinforces what I was saying wrt to not expecting any future-compatible behavior of system and thus reducing the scope of disklabel and 'c' partition arguments to the "static/current" codebase behavior. > So you shut up, loser. Just go away. > Ok then. Be happy, take it easy. leon.
Re: man pages conflict or clarification for mount_vnd, newfs and man 5 disklabel
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 behavior" then expect >> the likewise, albeit not-that-serious, replies. >> >> Besides, the code may well be acting like implementation and >> definition in one place, so no need to take such a heated bait to my >> light replies. I'll stop now :-) >> >> >> chill -- I don't mean to get a flame-war started, peace dude :-) > > Wow it is sunday night and you have used up all the manager-buzzword > speak for an entire month. What's next we have to go do some Agile > programming while implementing Extreme Programming ideas for UML > development that then becomes XML which we then can peruse for automated > testing because humans should not test? :-) :-) At least you exhibit some sense of humor :-) I am not advocating the over-standardisation, I am merely noting that in the absence of committed-to standards, it is futile to consider any future-incompatible 'mood' of the kernel's behavior wrt issues discussed (e.g. c partition). And I am also *not* advocating that one should always strive towards any future-incompatible behavior -- only that considering such possibilities wrt discussed 'kernel mood' would be a moot (pun intended) point. That's all. > If I am not VP material now I don't know what will... > ... I don't know, tell me: "what will" ? :-)
Re: man pages conflict or clarification for mount_vnd, newfs and man 5 disklabel
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 the matter discussed. > > Your opinion is wrong and uninteresting. The only thing you have > expressed so far is your detachment from the real world by implying that > some sort of retarded document written by committee retards is somehow > important. > I didn't say this (although I also did not express any support for having this general attitude towards standards as 'retarded documents written by retards'). I think your (and others) emotions are getting in a way of seeing the point I was making. I am not imposing a qualitative resolution that everything which is concerned with source code implementation must be standardized by a committee. You appear to have concluded that I am frowning at the fact that some parts of the source code are somehow not committee-standardized -- this is not so. I am simply noting (i.e. observing w/o blaming-others or anything of such sort) that, in the absence of such (or similar) standards, any consideration for what kernel's mood may bring in a future (e.g. arbitrary changes of interpretation of what "entire physical disk" equates to; ala "forward-compatibility") are not sufficient for the arguments at hand. In fact, I am not even suggesting that someone had made such arguments, I was simply enumerating the reasons I thought were relevant (and rather are easy to agree-on) when considering as to what "kernel's mood" may be interpreted in the context of the originally raised question (e.g. man pages implications for the disk to be functional without any disklabel being written to it [man 5 disklabel], the reasons given for not using c partition in [man vnconfig, caveats section] et al -- as per original email). >> >> > The source code _does_ define the behaviour. Exactly. Perhaps the >> > source code is wrong, but it *EXACTLY DEFINES THE BEHAVIOUR*. >> >> All I was saying that it is not always the case. For example: >> >> the code in various http client/server applications *implements* the >> behavior (correctly or incorrectly as it may be), but the behavior is >> *defined* elsewhere (e.g. a standard); > > And in the real world all these standards are treated as guidelines. Sure. But if such guidelines do exist -- should one not, at the very least, attempt/strive towards meeting them (provided, of course, that the standard/guidelines have been accepted by the implementing community)? We are basically starting to enter the whole discussion of viewing what "implementation" vs "definition" mean and this was so not the point of the original question. Besides, I am sure you already realize, that just because one may not be implementing the standard correctly -- it does not mean that one should simply ignore the standard altogether. > Anyone who has written code from a "standard" know this. This also > means that every person on this planet would interpret language the > same. In the open source world people can't even agree what the word > "free" means. > Not every person on this planet may interpret the language the same -- but this does not mean that everyone should abandon well-defined semantics attached to well-known words and start speaking their own non-interoperable junk. This is even more so w.r.t. technical/programming languages. >> >> similar things could be said about the code in c compiler vs the c >> standard et al. > > Show me 2 compilers and I'll show you 2 compilers that don't adhere to > the spec. This is a bit of a moot point -- and I am sure you realize this yourself. Not adhering to the specs does not equate to ignoring them altogether. >> Sometimes this may not be the case, of course, but to categorically >> imply that 'code defines behavior' is not right in my opinion. > > It does. Code is absolute, words on paper are not. 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 whilst there are cases when code represents both of such concepts in one place; there are other places when there simply *must* be multiple implementations (i.e. a source code of a given app/library) of a given behavior/interface (standard) so that different processes/boxes/entities/etc can inter-operate with each other. For instance: "Hello, how are you?" whether being written by me or by you, on screen or on paper is still better than "AOAURRAOREAr naoe as10 ao" ... right? >> On the other hand -- perhaps we differ in our understanding of the >> term "defines". You probably implying "defines" as in "results in a >> given behavior", I am implying "defines" more in terms o
Re: man pages conflict or clarification for mount_vnd, newfs and man 5 disklabel
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 whilst there are cases when code represents both of such
> concepts in one place; there are other places when there simply *must*
> be multiple implementations (i.e. a source code of a given
> app/library) of a given behavior/interface (standard) so that
> different processes/boxes/entities/etc can inter-operate with each
> other.
>
> For instance: "Hello, how are you?" whether being written by me or by
> you, on screen or on paper is still better than "AOAURRAOREAr naoe
> as10 ao" ... right?
I was, originally, a little hesitant of adding this extra note but
after some thought I might as well mention it... as it may provide
more clarity on the issue of this implementation vs definition
diversion from original question. This is only to show that, in fact,
I think we are saying common things, just in different terms.
I look at the actual ('raw') source code.
I then observe/derive a resulting behavior that such code would produce.
But I then also may want to optimize/improve the code (i.e. change it
with purposes of making the application perform better, faster, etc.)
-- but the question is: "by changing the code, some (insignificant)
aspects of the resulting behavior may change as well -- so which parts
of the resulting behavior are relied-upon/are-expected by other
applications and which fall in the 'irrelevant/insignificant or,
indeed, undefined' category"? One would need to know the boundaries of
code re-factoring when improving the *implementation* whilst still
retaining the interoperability-enabling interface/contract,
expected/*defined* behavior.
Whether such expectations (behavior definitions) are sometimes written
'inline' in the source code or in some standard publication is not the
main point really.
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.
Re: do newcomers need inspiration?
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. Sure, I agree. But that does not mean that: 1) there is such a thing as "specification/documentation" and it is not always the code itself (otherwise you would not be able to even have a statement of 'code <-> spec' differences). 2) having a difference between the "code <-> standard" does not imply an abandonment of further attempts towards a greater alignment with the aforementioned standard. In fact, I think all would agree on that (and this is why I was trying to reiterate that we are speaking of pretty much the same stuff, only differing in terms). leon.
Re: do newcomers need inspiration?
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 difference while dealing with two "languages": >> code <-> specification/documentation. > > Sure, I agree. > > But that does not mean that: my bad -- typo, the above line meant to be: "But it does mean that:" > > 1) there is such a thing as "specification/documentation" and it is > not always the code itself (otherwise you would not be able to even > have a statement of 'code <-> spec' differences). > > 2) having a difference between the "code <-> standard" does not imply > an abandonment of further attempts towards a greater alignment with > the aforementioned standard. > > In fact, I think all would agree on that (and this is why I was trying > to reiterate that we are speaking of pretty much the same stuff, only > differing in terms). > > leon.
Re: do newcomers need inspiration?
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 it says:"Do not cross-post or repeat post my bad. will note for future posts. leon.
Re: do newcomers need inspiration?
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. >> > -- >> >> :-) :-) :-) so many people who are so ready to express their logical >> and useful comments. > > To expound more eloquently upon the previous elocutions of the synaptic > processes which have transmigrated from cranium to keyboard, the > consensus of the community to which you address yourself is that your > expositions are of continual nuisance and drudgery, value-adding > naught to the dialogue, and providing a compelling case that your > cranium has lodged itself far past your rectum. :-) Continual nuisance in question is, surely, a by-product of more than 1 participant (and subsequently the naught-adding value act has been committed either by a few or by none -- given that such persons deemed the dialogue being worthy of further communication, discussions and replies... yourself not withstanding). Thus invariably, if indeed one does see it as a nuisance, one is free to withdraw oneself from the display of further hissy fits such as name-calling and cranium vs rectum assertions :-) :-) :-) Or, of course, one should not have to feel as if he/she was ever forced to produce any of such original hissy fits in the first place :-) :-) If such is your position -- feel free to lead by example :-) leon. ps people do need to relax and take it easy indeed (emotionally that is) :-)
Re: do newcomers need inspiration?
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 from anyone on the list. > > For everyones sake, just drop it. So far, I was relpying to comments directed back to me (i.e. I was not trying to continue conversation other than responding to comments that people decided to post back). If people really hated to dig through this, the best way would have been not to reply/engage in responses in the first place -- esp. when the vast majority of such engagements was not of any logical content but rather full of nonsensical name-calling. Then the whole chain of "reply-with-some-intent" vs "reply-with-hissy-fits" would have been broken long ago. However, I think you are correct -- I don't think there is any point or hope in further trying to extract any logical responses from this so-called conversation which has been been deteriorated to a series of farcical outbursts by some participants who insist on having the last-right-of-reply and combining such with an emotionally-unbalanced content. I will stop now -- congratulations and, as I'd expect no less, feel free to exercise your right of last-reply with yet another emotionally-charged outburst :-) Peace out, and really please do take it easy. leon.
Re: man pages conflict or clarification for mount_vnd, newfs and man 5 disklabel
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 question.
>>
>> Leon.
>
Hello Otto,
Firstly I'd like to thank you for replying with actually interesting
and constructive comments.
Secondly, I hope you don't mind, I'd like to address your post in an
"out of order" fashion. So... starting from the source-code of the
fsck_ffs...
>
> You might want to check the source of fsck_ffs. It contains code to
> locate alternate superblocks, and that code will not work for the 'c'
> partition.
>
I'm starting by looking in setup.c (in sbin/fsck_ffs). Namely the
implementation of 'calcsb' call, and it appears to work fine even if
'c' partition is passed to it, e.g. "/dev/rsvnd3c"
the line
'lp = getdisklabel(dev, devfd)'
produces disklabel fine even if there is no disk-label installed (in
coherence with man 5 disklabel)...
the line
'pp = &lp->d_partitions[*cp - 'a'];'
evaluates to 2 ('c' - 'a') and indeed the default disklabel has no
less than value of 3 for 'd_npartitions' so accessing the 3rd array
element for (c) partition info appears to be ok...
the above observations have been tested with a minor program (see
attachment or at the end of message).
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, plonk newfs on c partition then
clobber the starting 16k and see if fsck firstly detects bad
superblock and then recovers ok...
... and the tests appear to indicate that it does actually work.
I have attached the relevant files as a .tar attachment as well as
pasting at the end of the email (in case of attachments being stripped
at your end -- but mail agent may wrap badly...).
> I'm just back from vacation, so I'm late to jump in. The answer krw@
> has given is right. We (and as a consequence the kernel) take the
> liberty to change fields in disklabel, especially the entry for the
> 'c' partition.
If the above paragraph appears to relate to future code behavior --
then I'm fine with this as I have no expectations (nor requirements)
for future-compatibility w.r.t. disklabel (at least w.r.t. the context
of my original post). In other words, I was only interested on knowing
what happened on that particular version/release of the code and how
it correlated with the assertions/explanations in man pages (e.g.
vnconfig, caveats section)
> As for the slighly off-topic part of the thread: if we write a
> guideline into our manual page, it has a good reason to be there.
> Consider the man page to be your much needed authorative source of
> information.
Sure, but if there are multiple sources of information (multiple man
pages, code itself) then all should be in coherence w.r.t. each other.
So if man vnconfig (caveats section) gives certain
explanations/examples (e.g. implying the need for disklabel being
present on disk) then such should be reproducible and in accord with
other man pages (e.g. man 5 disklabel).
Otherwise (e.g. in case whet/if a normative point of reference for
behavior is not supported by other docs) there is not only a case for
starting ambiguity but also for a misleading conclusion.
I guess, if one definitively decided to reserve the 'c' partition for
special purposes, then instead of vnconfig caveat's section going into
detailed explanations/assertions as to why a given use of 'c'
partition would *not* work point blank (w/o testing such assertions)
it would rather be more succinct to state something like: "The 'c'
partition is reserved for non file-system use only. Consequently the
results of applying a file-system directly onto 'c' partition are
undefined." ... the 'undefined' being the keyword here (as opposed to
stating that it will *not* work, when in some cases it appears to work
just fine) -- thus allowing for practical observations to vary w/o any
point of contention w.r.t. man pages assertions.
It'd be, possibly, also a good idea to reduce the duplication of such
info and move the whole section into a disklabel man page.
Of course, it'd be even a finer point to exemplify elsewhere (not man
pages even) the examples of why/when the 'c' partition is practically
(or theoretically) likely to change on-the-fly (i.e. compare how the
"entire *physical* disk" representation may change arbitrarily)... but
Re: man pages conflict or clarification for mount_vnd, newfs and man 5 disklabel
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 >> empirical scenario: svnd an image, plonk newfs on c partition then >> clobber the starting 16k and see if fsck firstly detects bad >> superblock and then recovers ok... >> >> ... and the tests appear to indicate that it does actually work. > > If you had done this with non-default values for newfs and superblock > locations you would not be so lucky. Sure, but that is not the point. In fact, if you want to talk about non-default values for newfs, then I think 'c' partition or not, disklabel or not -- you could always generate a non-recoverable scenario as per man newfs: " -S sector-size [...] created (for example on a write-once disk). Note that chang- ing this from its default will make it impossible for fsck(8) to find the alternate superblocks if the standard superblock is lost. " ... and this is so way outside the context of my question. > >> I guess, if one definitively decided to reserve the 'c' partition for >> special purposes, then instead of vnconfig caveat's section going into >> detailed explanations/assertions as to why a given use of 'c' >> partition would *not* work point blank (w/o testing such assertions) >> it would rather be more succinct to state something like: "The 'c' >> partition is reserved for non file-system use only. Consequently the >> results of applying a file-system directly onto 'c' partition are >> undefined." ... the 'undefined' being the keyword here (as opposed to >> stating that it will *not* work, when in some cases it appears to work >> just fine) -- thus allowing for practical observations to vary w/o any >> point of contention w.r.t. man pages assertions. > > appearing to work sometimes is a special case of not working. it > doesn't mean it is working. > I didn't say this. I was saying: "ultimately stating that it *won't* work (when it sometimes does) is not correct; but saying that it is *undefined* to work would be more correct" -- see man 5 vnconfig, caveats section. leon.
Re: man pages conflict or clarification for mount_vnd, newfs and man 5 disklabel
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 :-)
>> >>
>> >> So now we can, perhaps, get back (if at all) to the man pages and what
>> >> they are implying wrt original question.
>> >>
>> >> Leon.
>> >
>>
>> Hello Otto,
>>
>> Firstly I'd like to thank you for replying with actually interesting
>> and constructive comments.
>>
>> Secondly, I hope you don't mind, I'd like to address your post in an
>> "out of order" fashion. So... starting from the source-code of the
>> fsck_ffs...
>>
>> >
>> > You might want to check the source of fsck_ffs. It contains code to
>> > locate alternate superblocks, and that code will not work for the 'c'
>> > partition.
>> >
>>
>> I'm starting by looking in setup.c (in sbin/fsck_ffs). Namely the
>> implementation of 'calcsb' call, and it appears to work fine even if
>> 'c' partition is passed to it, e.g. "/dev/rsvnd3c"
>>
>> the line
>> 'lp = getdisklabel(dev, devfd)'
>> produces disklabel fine even if there is no disk-label installed (in
>> coherence with man 5 disklabel)...
>>
>> the line
>> 'pp = &lp->d_partitions[*cp - 'a'];'
>> evaluates to 2 ('c' - 'a') and indeed the default disklabel has no
>> less than value of 3 for 'd_npartitions' so accessing the 3rd array
>> element for (c) partition info appears to be ok...
>
> But the next test (pp->p_fstype != FS_BSDFFS) will abort.
Not at all. Of course, I was *not* expecting to see FFS on 'c'
partition without first plonking newfs on it. Besides the attached
code (c++) includes this test and it is not tripped by this condition
(so yeah -- if I had simply 'vnconfig svnd3 ./image' then, naturally,
no FFS on it; but the test/questions obviously were related to putting
an fs on 'c' partition ('newfs svnd3c') vs the "writing disklabel and
newfs on 'a'" for example).
>>
>> the above observations have been tested with a minor program (see
>> attachment or at the end of message).
>>
>> 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, plonk newfs on c partition then
>> clobber the starting 16k and see if fsck firstly detects bad
>> superblock and then recovers ok...
>>
>> ... and the tests appear to indicate that it does actually work.
>
> 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 place. Or maybe another scenario where the first alternate
> is corrupted too, who knows? Also, disklabel test should preferable
> include reboots to force the on-disk label to be read or spoofed
> again.
Ok sweet -- thanks for this. I'll try these cases as well (w/o
non-default settings -- as I'd replied to an earlier email, I don't
consider such to be within the context of the discussion).
>
> Showing that a single scenario works for you doesn't show any validity
> in the general sense.
>
I wasn't trying to show validity of the general sense here. I was
trying to show invalidity of categorical statements made in vnconfig
man page... but I will test with a reboot as well...
> in case of disaster. A new version of OpenBSD might even be that
> disaster (for you).
Once again -- forward-compatibilty is not my requirement (a new
version may have lots of different non backwards-compatible changes,
who knows?)
Leon.
Re: man pages conflict or clarification for mount_vnd, newfs and man 5 disklabel
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 place. Or maybe another scenario where the first alternate >> is corrupted too, who knows? Also, disklabel test should preferable >> include reboots to force the on-disk label to be read or spoofed >> again. > > Ok sweet -- thanks for this. I'll try these cases as well (w/o > non-default settings -- as I'd replied to an earlier email, I don't > consider such to be within the context of the discussion). > Ah -- you are 100% correct. Although different blocksizes et al appear to work fine, the re-spoofing clears the BSDFFS detection of filesystem in the spoofed disklabel (if one cleans out the 1st blocksize bytes on 'raw' disk and then re-svnds the whole lot). Thanks for you help on this. In such a case, there is just 1 more thing I have spinning in my head -- w.r.t. to how likely a 'recovery' would be if the disklabel itself was written to disk (ala mr. proper) and then the disk sectors where the disklabel resides would be clobbered -- would it not have the same effect w.r.t. killing the recovery chances? In essence, the above test of clobbering some data on raw disk is equivalently dramatic regardless of whether disklabel is written or not or whether 'c' partition is used for ffs or not... Consequently, I think, it is not as much about the disklabel info being unavailable when using c partition directly (as vnconfig appears to imply) -- because it is, indeed, available (other than when corrupting raw disk data -- in which case even the valid disklabel installation would not help)... ... but rather it is about *written* disklabel being guaranteed to remain intact even if/when 'c' partition is changed on the fly by the kernel (e.g. in future system releases which is not in my question-scope). 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 (?) leon. >> >> Showing that a single scenario works for you doesn't show any validity >> in the general sense. >> > > I wasn't trying to show validity of the general sense here. I was > trying to show invalidity of categorical statements made in vnconfig > man page... but I will test with a reboot as well... > > >> in case of disaster. A new version of OpenBSD might even be that >> disaster (for you). > > Once again -- forward-compatibilty is not my requirement (a new > version may have lots of different non backwards-compatible changes, > who knows?) > > Leon.
Re: man pages conflict or clarification for mount_vnd, newfs and man 5 disklabel
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 phrased it differently a bit: In the examples of *corrupted* disk-sectors though there appears not to be much difference -- i.e. "disk sectors hosting superblocks being corrupted" vs "disk sectors hosting disklabel being corrupted... ...Perhaps there is a more likely chance for a superblock being corrupted by some s/w bug or activity as opposed to a disklabel being corrupted?
Re: man pages conflict or clarification for mount_vnd, newfs and man 5 disklabel
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 could use the same principles to 'back up' the actual ffs superblock sectors to a separate file/location/disk (dd if=/dev/rsvnd3c of=some_other_storage bs=1 count=xxx) and during restoration clobber it back onto unused/blank 'c' partition :-) :-) ;-) The main question would be what info is updated to superblock during fs use (the 'clean' / 'last cleaned' flags could be considered insignificant though). Interestingly enough (mostly for my understanding), if we are talking about backing/saving disklabel to a file and why the following practices would not work (for reasons other than 'c' partition interpretation-change): vnconfig svnd3 ./image_file # being a badboy... newfs svnd3c then running disklabel and "saving" to asii file should not be seen as allowing for restoration of 'c' partition (disklabel -R svnd3 ascii_file) with BSDFFS on it -- even after clobber-and-reboot has been applied to disk as per previous experiments... Because (?) this would not work as the *re*writing of disklabel to disk (which had none previously stored on it) would end up stepping on sectors previously used for other things... (if such was decided to be written to the actual image file)... Anyway -- thanks for your info/thoughts on this ! > The main thing is: a spoofed label is not very useful if non-default > ffs values are used because the cyl per group, blocksize and fragsize > fields are not recorded. And even if you use an on-disk label, the Interestingly, newfs -b 32786 -f 4096 svnd3c (directly on 'c' partition) survives reboot. That is after reboot disklabel svnd3 shows 'c' partition as BSDFFS with aforementioned (custom?) blocksizes and fragsizes. leon.
Re: man pages conflict or clarification for mount_vnd, newfs and man 5 disklabel
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 backup sounds nice. Although I suppose I could use the same > principles to 'back up' the actual ffs superblock sectors to a > separate file/location/disk (dd if=/dev/rsvnd3c of=some_other_storage > bs=1 count=xxx) and during restoration clobber it back onto > unused/blank 'c' partition :-) :-) ;-) The main question would be what > info is updated to superblock during fs use (the 'clean' / 'last > cleaned' flags could be considered insignificant though). Ah, I am also beginning to think that superblock would be accessed (e.g. written-to) more often than disklabel (thus higher corruption risk)... http://www.scs.stanford.edu/nyu/04fa/notes/l8d.txt " [...] Superblock also contains non-replicated "summary info." What's this? # blocks, fragments, inodes, directories [...] " So, 1 more reason to have written disklabel for increased recovery chances... :-) leon.
