On Monday 18 October 2010, Raimo Niskanen wrote:
> It seems the frontend fsck does not care about the special device name
> but leaves it up to the backend fsck_ffs to interprete it, so as long
> as fsck can deduce from /etc/fstab or from command line arguments
> which backend to call, there is no problem.
The problem is that readlabelfs() did not understand disklabel UIDs, until
recently. This meant that fsck(8) could not determine which backend to use
unless it could derive the information from elsewhere (i.e. /etc/fstab or
the -t option).
> However, it is annoying that e.g fsck_msdos does not handle
> UID special device names. The device name _is_ valid on the disk level,
> not on the slice level - you can use "sysctl hw.disknames" to translate
> the UID into current /dev/ node, so it seems that the frontend fsck
> would be the logical place to do the translation.
>
> My 2c, not knowing better... The current implementation feels 3/4 done.
You are indeed correct - it is not complete. The disklabel UID implementation
was started during h2k10. It has been a long journey through a lot of dark
twisty mazes and in a lot of cases I have ended up working on problems that
are unrelated, however ones that would prevent forward progress on the
disklabel UID front. There have also been many design challenges - we want it
to work reliably and in order to achieve this we have to avoid potential
races between mappings and usage.
I think disklabel UIDs became largely usable around 5 months ago, however
there were still some major caveats especially with regards to disks that
were attached after boot. This was only addressed 2 months ago, which was
unfortunately after 4.8 had been tagged. Most of the remaining areas where
disklabel UIDs are not useable are slowly being addressed - hopefully over
the next few months there won't be too many places that they do not work.
> On Fri, Oct 15, 2010 at 08:57:36AM +0200, Jiri B. wrote:
> > > This works iff you list the partition by uid in /etc/fstab, e.g.
> > >
> > > $ uid=d3f6b8c752d5141a.a
> > > $ grep $uid /etc/fstab
> > > d3f6b8c752d5141a.a / ffs rw 1 1
> > > $ fsck -f $uid
> > > ** /dev/wd0a (d3f6b8c752d5141a.a) (NO WRITE)
> > > ** Last Mounted on /
> > > ** Root file system
> > > ** Phase 1 - Check Blocks and Sizes
> > > ** Phase 2 - Check Pathnames
> > > ** Phase 3 - Check Connectivity
> > > ** Phase 4 - Check Reference Counts
> > > ** Phase 5 - Check Cyl groups
> > > 4270 files, 57007 used, 21613 free (1093 frags, 2565 blocks, 1.4%
> >
> > fragmentation)
> >
> > > If the fstab entry uses /dev/Xd0a format then it fails as reported.
> >
> > I don't see reason why `fsck -f' (or without -f) should depend on
> > /etc/fstab. It's not preen mode.
> >
> > I discovered this because I use softraid crypto and having 'fs_passno'
> > equal to 0 in
> > fstab, then doing fsck stuff later, after bringing up devices with
> > passfile...
> >
> > jirib
--
"Stop assuming that systems are secure unless demonstrated insecure;
start assuming that systems are insecure unless designed securely."
- Bruce Schneier
