On 7/27/09, Kenneth R Westerback <kwesterb...@rogers.com> wrote: > On Mon, Jul 27, 2009 at 11:11:21AM +1000, leon zadorin wrote: >> On 7/27/09, Kenneth R Westerback <kwesterb...@rogers.com> 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' partition describes the entire physical disk, is automati- > cally created by the kernel, and cannot be modified or deleted by > disklabel.
To me it sounds precise-enough (i.e. 'describes the *entire* *physical* disk' vs "special partition that the kernel freely changes as the mood hits it" is not a slight difference in description). > Feel free to use 'c' for anything you want. Just don't complain, or expect > short shrift when you do, if it blows up later on because the kernel is :-) I don't recall expressing any complaints or having any short shrift expectations. In fact, all I am doing is trying to understand the internals/actual behavior model in a more intimate way. > making free use of it by arbitrarily changing its limits to reflect a > new concept of 'whole disk'. 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. leon.
