Sun Microsystems Systems Architecture Committee
Subject	New Size Suffixes for mount_tmpfs
Submitted by	Ozgur Leonard
File	PSARC/2001/329/opinion.html
Date	May 9^th, 2001
Committee	Joseph Kowalski (opinion written by Lee Duncan), Lisa Camesano, Ralph Campbell, John Danielson, Terrence Miller, Andy Rudoff, Glenn Skinner, Andrew Tucker
Steering Committee	SOESC

1. Summary

This case enhances the mount_tmpfs(1m) command so that sizes can be specified to it in kilobytes, megabytes, gigabytes, and terabytes using standard abbreviations. Previously, only kilobytes and megabytes could be specified.

2. Decision & Precedence Information

The project is approved as specified in reference [1]. The project may be delivered in an update/patch release of Solaris

3. Interfaces

Interfaces Exported
Interface Name	Classification	Comment
New size suffixes for “-o size=XXX”	Standard	Defined by mount_tmpfs(1m) man page

4. Opinion

This case was originally proposed as a fast track with a fair amount of email discussion, which centered on the following areas.

4.1 Use of “b” To Mean Bytes

The original proposal suggested the suffix “b” stand for bytes, but committee members suggested this conflicted with some existing commands, such as od(1) and mkfile(1), where a size suffix of “b” is taken to mean 512-byte blocks. In addition, a suffix is not needed as a shortcut to mean bytes, since a number with no suffix already means bytes.

4.2 Support of “t” To Mean Terabytes

The original proposal did not suggest a suffix for terabytes, but agreed to add it after discussion with the committee showed general agreement that planning for future (larger) amounts of memory usage would be wise.

4.3 Which mount(1m) Subcommands To Update

The project team originally suggested updating the mount_xmemfs(1m) command as well as mount_tmpfs(1m), but because of size limitations in mount_xmemfs(1m) on the IA32 platform, this command did not need the terabyte suffix. Since mount_xmemfs(1m) already supported all the other suffixes in this proposal, there was no need to update it.

4.4 Need For A Common Standard and Library

Some members of the committee felt that some sort of library routine or routines should be created to parse size specifications, including the suffix. In this way, the duplicate work each command currently has to do to parse these values is consolidated. In addition, this would ensure that all commands using this interface interpreted size suffixes in the same way, reducing end-user confusion. The project team agreed in principle, but said that even if such a library existed, it would require major changes in this particular case to use such a library. The committee did not want to impede this project for a long-standing problem, so reluctantly agreed.

5. Minority Opinion(s)

None.

6. Advisory Information

The review committee advises the steering committee that some thought should be given to creating a standard specification for size suffixes. This standard could be implemented as one or more common library routines, thus eliminating duplication and end-user confusion.

Appendices

Appendix A: Technical Changes Required

None

Appendix B: Technical Changes Advised

None

Appendix C: Reference Material

Unless otherwise stated, path names are relative to the case directory (PSARC/2001/329).

1. mail
case mail log file