On 8/4/09, Otto Moerbeek <o...@drijf.net> 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
that is more of a wish-list.
Anyway, here are the quick test hacks/files:
the practical test (done on OpenBSD zion 4.5 GENERIC#1749 i386,
Intel(R) Core(TM)2 Duo CPU E6550 @ 2.33GHz)
the shell script:
#!/bin/sh
function bail
{
echo "Colud not ${*}."
exit 1
}
echo "Setting up the test scenario before corrupting"
dd if=/dev/zero of=./image bs=1m count=77 || bail "dd initial image"
vnconfig svnd3 ./image || bail "vnconfig svnd"
newfs svnd3c || bail "newfs"
fsck_ffs -f /dev/svnd3c || bail "initially fsck"
mount /dev/svnd3c /mnt || bail "initially mount"
dd if=/dev/arandom of=/mnt/test
cp /mnt/test ./image.test || bail "back up comparison file"
cmp /mnt/test ./image.test || bail "sanity check for files comparison"
umount /mnt || bail "initially unmount"
dd if=/dev/zero of=/dev/svnd3c bs=1 count=16000 || bail "clobber superblock"
echo "Executing after-effect..."
fsck_ffs -f /dev/svnd3c || bail "recovery fsck"
mount /dev/svnd3c /mnt || bail "recovery mount"
cmp /mnt/test ./image.test || bail "recovery check for files comparison"
umount /mnt || bail "recovery unmount"
vnconfig -u svnd3 || bail "recovery (un)vnconfig svnd"
echo "All done -- fsck_ffs does work on 'c' partition afterall..."
And the light ++c hack to see if disklabel is generated on the fly for
DIOCGDINFO call on disk with 'c' partition only:
#include <sys/param.h>
#include <sys/time.h>
#include <ufs/ufs/dinode.h>
#include <ufs/ffs/fs.h>
#include <sys/stat.h>
#include <sys/ioctl.h>
#include <sys/disklabel.h>
#include <errno.h>
#include <fcntl.h>
#include <stdio.h>
#include <stdlib.h>
#include <string.h>
#include <ctype.h>
#include <unistd.h>
#include <iostream>
#include <stdexcept>
struct autofd {
int const fd;
autofd(char const * const dev)
: fd(::open(dev, O_RDONLY)) {
if (fd < 0)
throw ::std::runtime_error("can't open device");
}
~autofd()
{
::close(fd);
}
operator int ()
{
return fd;
}
};
int
main()
{
try {
char const * const dev = "/dev/rsvnd3c";
struct stat statb;
if (stat(dev, &statb) < 0)
throw ::std::runtime_error("stat dev");
if (!S_ISCHR(statb.st_mode))
throw ::std::runtime_error("not a char dev");
autofd fd(dev);
struct disklabel lab;
if (::ioctl(fd, DIOCGDINFO, reinterpret_cast<char *>(&lab)) < 0)
throw ::std::runtime_error("get disklabel");
if (lab.d_npartitions < 3)
throw ::std::runtime_error("no c partition
placeholder");
struct disklabel::partition & pp(lab.d_partitions[2]);
if (pp.p_fstype != FS_BSDFFS)
throw ::std::runtime_error("not labeled as bsd fs");
::std::cout <<
"sector size: " << lab.d_secsize << "\n" <<
"sectors: " << lab.d_nsectors << "\n" <<
"tracks: " << lab.d_ntracks << "\n" <<
"sectors per cylinder: " << lab.d_secpercyl << "\n" <<
"partition size in sectors: " << pp.p_size << "\n" <<
"partition start sector: " << pp.p_offset << "\n";
return 0;
} catch (::std::exception const & e) {
::std::cerr << "Bailing -- got an error: " << e.what() << "\n";
} catch (...) {
::std::cerr << "Bailing -- unknown exception caught\n";
}
return -1;
}
The code is built with:
gcc main.cc -lstdc++ -lm
Leon.
[demime 1.01d removed an attachment of type application/x-tar which had a name
of leontest.tar]
