On Wed, Jun 4, 2008 at 10:46 PM, Mike Gerdts <mgerdts at gmail.com> wrote:
> I've long been annoyed by the fact that mount(1M) isn't smart enough
> to figure out the file system type but fstyp(1M) is. ?As I was writing
> the code to fix this annoyance, I found the reason why.
Thank you all for your feedback. Based upon that feedback I have put
together this one-pager. If anyone here has a desire to ARC-sponsor
this for me, I would be most appreciative. Else, I'll go trolling on
request-sponsor for an ARC-sponsor and a putback sponsor.
Template Version: @(#)onepager.txt 1.31 07/08/08 SMI
This information is Copyright 2008 Mike Gerdts <mgerdts at gmail.com>
1. Introduction
1.1. Project/Component Working Name:
auto-fstyp: auto file system type detection by file system utils
1.2. Name of Document Author/Supplier:
Mike Gerdts <mgerdts at gmail.com>
1.3. Date of This Document:
06/05/2008
1.4. Name of Major Document Customer(s)/Consumer(s):
1.4.1. The Community you expect to review your project:
ON
1.4.2. The ARC(s) you expect to review your project:
PSARC
1.5. Email Aliases:
1.5.2. Responsible Engineer: mgerdts at gmail.com
1.5.4. Interest List: on-discuss at opensolaris.org
2. Project Summary
2.1. Project Description:
This project seeks to obsolete /etc/default/fs in favor of
using file system type detection logic built into the existing
consumers of /etc/default/fs. The existing consumers include
clri(1M), df(1M), ff(1M), fsck(1M), mount(1M), and
volcopy(1M).
2.2. Risks and Assumptions:
volcopy(1M) does not specify the order of the operands, making
it difficult to reliably use one of the operands as the device
to use for file system type detection. Currently, the only
file-system specific version of volcopy is volcopy_ufs. The
examples within volcopy.c suggest that volcopy(1M) is/was
popular with tapes. This suggests that attempts to determine
the file system type may introduce tape positioning bugs.
Considering all of this and the unlikelihood that volcopy
will be written for other widely used file systems, simply
defaulting volcopy to ufs without the use of /etc/default/fs
seems to be the right thing to do.
default_fs(4) may be used by unknown third-party utilities.
It is believed that this is highly unlikely.
Currently libfstyp.so.1 lives in /usr/lib. This project will
add a dependency on libfstyp to mount(1M) and fsck(1M) which
are essential in times when /usr may not be available.
Additionally, these commands may be essential in ramdisk
boot images. This project will move libfstyp.so.1 to /lib,
resulting in approximately 20 KB additional space required in
/lib and resulting ramdisk images.
libfstyp(3LIB) makes use of plug-ins that reside in
/usr/lib/fs/hsfs. These plug-ins are unlikely to be available
during early boot and as such ufs mounts that previously
worked may not work in the absense of vfstab entries unless
"-F ufs" is used.
3. Business Summary
3.1. Problem Area:
Usability of several commands could be improved by integrating
existing file system type detection with those commands that
currently use /etc/default/fs.
3.2. Market/Requester:
OpenSolaris community
3.3. Business Justification:
Makes OpenSolaris more friendly to newcomers and others.
3.4. Competitive Analysis:
// Who are the current and anticipated players in this market?
3.5. Opportunity Window/Exposure:
// Time-to-market window, if any, and precision.
3.6. How will you know when you are done?:
/etc/default/fs is no longer needed because clri(1M), df(1M),
ff(1M), fsck(1M), and mount(1M) can automatically determine
the file system type.
4. Technical Description:
4.1. Details:
Each of the affected commands reads the default file system
from /etc/default/fs via calls to default_fstype() in
usr/src/cmd/fs.d/deffs.c. Calls to default_fstype() will be
replaced by calls to a new function read_fstype(), which is
derived from main() from fstyp(1M).
4.2. Bug/RFE Number(s):
// List any bug/rfe's which will be addressed by this proposed
// change.
4.3. In Scope:
// Aspects that are in scope of this proposal if not obvious from
// the above.
4.4. Out of Scope:
// Related aspects that are out of scope for this proposal if not
// obvious from the above.
4.5. Interfaces:
/etc/default/fs is removed.
The behavior of clri(1M), df(1M), ff(1M), fsck(1M), and
mount(1M) are changed in the abense of a matching /etc/vfstab
entry and the absense of the "-F fstype" option and argument.
Rather than using /etc/default/fs, automatic file system type
detection logic is used.
The behavior of volcopy is changed such that it simply assumes
ufs in the absense of a "-F fstype" option and argument.
4.6. Doc Impact:
The man page default_fs(4) is removed, as are all references
to it in other man pages.
The man pages clri(1M), df(1M), ff(1M), fsck(1M), and
mount(1M) are changed as follows:
OPTIONS
-F Specify the FSType on which to operate.
The FSType should either be specified
here or be determinable from /etc/vfstab
by matching the special with an entry in
the table, or by automatic file system
type detection using libfstyp(3LIB).
References to libfstyp(3LIB) are added to those man pages.
The man page volcopy(1M) is changed as follows:
OPTIONS
-F Specify the FSType on which to operate.
The FSType should either be specified
here or be determinable from /etc/vfstab
by matching the special with an entry in
the table. If not specified and not found
in /etc/vfstab, the default value of ufs
is used.
4.7. Admin/Config Impact:
There are no known administrative tools that manage
/etc/default/fs. Additionally, the program changes are not
expected to impact any currently functioning administrative
utilities.
4.8. HA Impact:
None.
4.9. I18N/L10N Impact:
None.
4.10. Packaging & Delivery:
/usr/lib/libfstyp.so.1 is moved from /usr/lib to /lib. A
symbolic link is added in /usr/lib for compatibility. This
will move libfstyp.so.1 from SUNWcsl to SUNWcslr.
Upgrade shall remove /etc/default/fs.
4.11. Security Impact:
No known security impact.
4.12. Dependencies:
// List all dependencies that this proposal has on other
// proposals, components or products. Include interface
// specifics above in the interfaces section; list component
// version requirements here.
5. Reference Documents:
Initial discussion on on-discuss at opensolaris.org:
http://mail.opensolaris.org/pipermail/on-discuss/2008-June/000128.html
6. Resources and Schedule:
6.1. Projected Availability:
July, 2008
6.2. Cost of Effort:
Development - 2 weeks part time from an OpenSolaris contributor
6.4. Product Approval Committee requested information:
6.4.1. Consolidation or Component Name: ON
6.4.7. Target RTI Date/Release:
Build 94, 95, or 96 (July - August 2008)
6.4.8. Target Code Design Review Date:
June 23, 2008
6.5. ARC review type:
FastTrack
6.6. ARC Exposure: open
6.6.1. Rationale: Part of OpenSolaris
7. Prototype Availability:
7.1. Prototype Availability:
mount(1M) only available now at
http://cr.opensolaris.org/~mgerdts/mount/
7.2. Prototype Cost:
1 partial day.
--
Mike Gerdts
http://mgerdts.blogspot.com/
