On 8/5/09, Ted Unangst <ted.unan...@gmail.com> wrote:
> On Tue, Aug 4, 2009 at 12:17 PM, leon zadorin<leonleo...@gmail.com> 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.
