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.
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. 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 -- / Raimo Niskanen, Erlang/OTP, Ericsson AB
