Make fsck(8) default to "ufs", like eg mount(8) does.
Details
Details
Diff Detail
Diff Detail
- Repository
- rS FreeBSD src repository - subversion
- Lint
Lint Not Applicable - Unit
Tests Not Applicable
Event Timeline
| sbin/fsck/fsck.c | ||
|---|---|---|
| 218 ↗ | (On Diff #25234) | I would combine both old and new code. I.e. do set type to ufs, but also issue a warning. |
Comment Actions
Wouldn't that defeat the purpose of having the default? Other utilities don't issue warnings in this case, they just silently go with default.
Comment Actions
Which other utilities ?
After you asked the question, I started thinking that fall back to ufs might be in fact unsafe. UFS superblock might very well survive re-formatting of the volume into different file type. So for typical scenario where device is absent from fstab, where disk is moved into another machine, and you run fsck without specifying a type, fsck_ffs might start correcting non-UFS data. There are other safeties like '-y' switch, but I think that it would be stressful for a user to see the long error list from fsck.
Comment Actions
I think this is perfectly fine now that GPT doesn't provide this information (disklabel used to). But maybe we need to hack getfstype() to grok GPT labels like it used to grok disklabel().
mount silently falls back to ufs, though I'm not sure the mechanism it uses.
Comment Actions
Konstantin - _all_ the utilities. Namely newfs and mount. They all default to ufs. It's logical for fsck to do the same. Especially that other systems people are used to don't require one to specify the filesystem by hand either.
Comment Actions
mount is (much) less destructive than fsck. My point is that fsck is used in situation where being too aggressive by default is not the best choice. I.e. even the presence of valid UFS superblock does not imply that fsck can safely write to the volume making 'fixes'.
newfs is the wrong example in the series, since whatever variant is used, volume is destroyed anyway.
I do not to block you hard, though.