I'm submitting this fast-track for Nagakiran Rajashekar, timeout on
8/4/2008.
- Dan
Template Version: @(#)onepager.txt 1.35 07/11/07 SMI
Copyright 2007 Sun Microsystems
Sun Proprietary/Confidential: Internal Use Only: Engineering Need-to-Know
1. Introduction
1.1. Project/Component Working Name:
EOF of Cache FileSystem (cachefs)
1.2. Name of Document Author/Supplier:
Nagakiran Rajashekar
1.3. Date of This Document:
07/22/08
1.3.1. Date this project was conceived:
01/22/08
1.4. Name of Major Document Customer(s)/Consumer(s):
1.4.1. The PAC or CPT you expect to review your project:
Solaris PAC
1.4.2. The ARC(s) you expect to review your project:
PSARC
1.4.3. The Director/VP who is "Sponsoring" this project:
Chris Armes
1.4.4. The name of your business unit:
Solaris RPE
1.5. Email Aliases:
1.5.1. Responsible Manager:
Vidya.Sakar at SUN.COM, Lisa.M.Chatham at SUN.COM
1.5.2. Responsible Engineer:
Nagakiran.Rajashekar at SUN.COM
1.5.3. Marketing Manager:
Kamal.Varma at SUN.COM
1.5.4. Interest List:
cachefs-eof-discuss at sun.com
2. Project Summary
2.1. Project Description:
This is a proposal to EOF Cache Filesystem (cachefs). Cachefs
was introduced
in Solaris via PSARC case http://sac.sfbay/PSARC/1991/042/ .
Cache Filesystem
has been in a sustaining mode since 1999, and no new features
are being
entertained, mainly due to complexity and fragile nature of the
product.
There has been huge improvements in the area of networking
and memory which has led to NFS itself as a choice of Network
based Filesystem, without requiring a special disk based cache
filesystem.
This is an attempt to remove this out of date filesystem from
Solaris
code base to prevent people from deploying it in mission
critical business
environments.
2.2. Risks and Assumptions:
While removal of the cachefs product itself doesn't pose any
immediate
threat to Solaris Operating Environment, third party products
directly using cachefs will fail.
Sun internal product AutoClient which was built on cachefs has
already been
EOSL'ed and the code has been removed from Solaris source base,
as detailed
in http://sac.sfbay/PSARC/2004/266/ .
Solaris cachefs EOF Announcement process should take care of
communicating
these changes to Sun's Customers, ISVs, and engineering
community.
3. Business Summary
Cachefs has been designed with a very specific environment in mind,
and the conditions which encouraged such a product have completely
changed. We have networks that are in the order of Gigabits and
filesystems that make effective use of system RAM for caching data
today.
Caching and maintaining the cache which are consistent with the
actual filesystems
is a huge overhead and is the cause of all complexities with
cachefs today.
cachefs has knowledge of the underlying filesystems and makes it
less modular
and difficult to support. Makes it difficult to integrate with
new filesystems (like ZFS).
Retaining a product that is aging fast and tough to support
is an expensive business.
3.1. Problem Area:
cachefs has been designed with read-only workloads in mind.
Inappropriate deployments of cachefs have lead some customers to
spend
time and money fixing the issues that surfaced later because
of scalability and complexity of cachefs design.
For example : Using cachefs in an environment where the access
is heavily read-write, could lead to kernel deadlocks and
performance
issues.
Currently there are no suitable testsuites to test cachefs
making it all the more diffcult to provide fixes to this
aging and fragile product.
3.2. Market/Requester:
3.3. Business Justification:
Cachefs has been designed at times where access to NFS servers
were unacceptably slow. And NFS servers weren't scaling to allow
more clients. It was designed at a time to provide faster access
to then slower CD-ROM devices.
One of the other capability cachefs provides is disconnected mode;
the ability to have a common server providing access to key
executables
which could be locally cached allowing the user to work offline or
when the server was down.
The idea was that rather than having to maintain software on all
the
individual user systems, only the server had to be maintained.
But this ability provide centralized software control is largely
replaced by Sunray today.
Further the equations have changed, you have NFS servers scaling
enough
to allow large number of NFS clients and caching as much of
data as possible at the client side. Removing cachefs doesn't leave
a gap in functionality as the existing NFS implementation already
takes care of scalability and performance issues, which were
intended
to be addressed by cachefs.
NFSv4 which is the default NFS version in Solaris 10 only provides
pass-through support for cachefs. Mostly because cacheFS makes
inherent
assumptions about the back filesystem and the local filesystem
where
cache is created.
CacheFS is not able to scale to the current workloads without
compromising on the consistency of the data. Cachefs is not a
general
solution for all caching needs and is a support nightmare.
3.4. Competitive Analysis:
3.5. Opportunity Window/Exposure:
3.6. How will you know when you are done?:
Project is complete once the cachefs functionality is removed
from the
Solaris code base.
4. Technical Description:
4.1. Details:
As part of this proposal all the code pertaining to cachefs and
cachefs utilities will be removed. There will be man page
removals and changes where
required. The applicable packages will be modified in the
package cluster.
NFS is a fine alternative today. cachefs initially tried to address
the problem of scalability and speed which is met by NFS today
without
compromising on data integrity. More importantly NFS v4
which is the default version on the latest release of Solaris
has only pass through support for cachefs, owing to the complexity
and assumptions made by cachefs with respect to NFS v2/v3 and UFS.
NFS v4 however does some aggresive caching in certain cases
which allow faster
access to remote data, and hence offsets the lack of support for
cachefs.
There were assumptions about slow CD-ROM drives made by cachefs.
It is possible today to cache a lot of data at the filesystem level,
or use ramdisk as an alternative.
Alternatively entire DVD/CD-ROM images can be accessed from disk
using lofi(7D) on Solaris.
cachefs in most cases needs design changes to address simple
problems. And this is not an appropriate option for a product
that is
in sustaining mode.
Examples :-
http://monaco.sfbay/detail.jsf?cr=6368798
http://monaco.sfbay/detail.jsf?cr=4952819
http://monaco.sfbay/detail.jsf?cr=6181967
4.2. Bug/RFE Number(s):
The work for cachefs EOF removal will be tracked via bug:
http://monaco.sfbay/detail.jsf?cr=6729252
4.3. In Scope:
None.
4.4. Out of Scope:
None.
4.5. Interfaces:
This proposal attempts to obsolete the following external
interfaces.
NAME old
new
==========================================================================
mount_cachefs Public
Obsolete
fsck_cachefs Public
Obsolete
cfsadmin Public
Obsolete
cachefsstat Public
Obsolete
cachefspack Public
Obsolete
cachefslog Public
Obsolete
cachefsd Private
Obsolete
/usr/include/sys/fs/cachefs_dir.h Public
Obsolete
/usr/include/sys/fs/cachefs_dlog.h Public
Obsolete
/usr/include/sys/fs/cachefs_filegrp.h Public
Obsolete
/usr/include/sys/fs/cachefs_fs.h Public
Obsolete
/usr/include/sys/fs/cachefs_fscache.h Public
Obsolete
/usr/include/sys/fs/cachefs_ioctl.h Public
Obsolete
/usr/include/sys/fs/cachefs_log.h Public
Obsolete
Following type of ioctls used by the userland cachefs
programs/daemons will be obsoleted by this proposal.
All these interfaces are currently project private and have no
external visibility
and will be unavailable as part of the proposal.
NAME Currently Will be
=======================================================
_FIOCOD Project private Obsolete
_FIOSTOPCACHE Project private Obsolete
CACHEFSIO_PACK Project private Obsolete
CACHEFSIO_UNPACK Project private Obsolete
CACHEFSIO_PACKINFO Project private Obsolete
CACHEFSIO_DCMD Project private Obsolete
set of subcommands to CACHEFSIO_DCMD that will be obsoleted aswell.
enum cfsdcmd_cmds {
CFSDCMD_DAEMONID, CFSDCMD_STATEGET, CFSDCMD_STATESET,
CFSDCMD_XWAIT, CFSDCMD_EXISTS, CFSDCMD_LOSTFOUND,
CFSDCMD_GETINFO,
CFSDCMD_CIDTOFID, CFSDCMD_GETATTRFID, CFSDCMD_GETATTRNAME,
CFSDCMD_GETSTATS, CFSDCMD_ROOTFID,
CFSDCMD_CREATE, CFSDCMD_REMOVE, CFSDCMD_LINK,
CFSDCMD_RENAME,
CFSDCMD_MKDIR, CFSDCMD_RMDIR, CFSDCMD_SYMLINK,
CFSDCMD_SETATTR,
CFSDCMD_SETSECATTR, CFSDCMD_PUSHBACK
};
4.6. Doc Impact:
Following man pages will be modified.
mount(1M)
mnttab(4)
vfstab(4)
fsck(1M)
automount(1M)
Following man pages will be removed
mount_cachefs
cfsadmin
cachefspack
fsck_cachefs
cachefsstat
cachefslog
cachefswsssize
cachefsd
4.7. Admin/Config Impact:
a. Mount command will no longer support cachefs and related options
b. cfsadmin, cachefspack, cachefslog, cachefswsssize commands
will cease to exist
c. autofs will no longer recognize cachefs option.
4.8. HA Impact:
4.9. I18N/L10N Impact:
4.10. Packaging & Delivery:
Files will be removed from the below mentioned packages.
SUNWcsr
/etc/init.d/cachefs.daemon
SUNWcsu
/usr/lib/fs/cachefs
/usr/lib/fs/cachefs/cachefsd
/usr/lib/fs/cachefs/cachefslog
/usr/lib/fs/cachefs/cachefspack
/usr/lib/fs/cachefs/cachefsstat
/usr/lib/fs/cachefs/cachefswssize
/usr/lib/fs/cachefs/cfsadmin
/usr/lib/fs/cachefs/cfsfstype
/usr/lib/fs/cachefs/cfstagchk
/usr/lib/fs/cachefs/dfshares
/usr/lib/fs/cachefs/fsck
/usr/lib/fs/cachefs/mount
/usr/lib/fs/cachefs/share
/usr/lib/fs/cachefs/umount
/usr/lib/fs/cachefs/unshare
/usr/bin/cachefspack
/usr/bin/cachefsstat
/usr/sbin/cachefslog
/usr/sbin/cachefswssize
/usr/sbin/cfsadmin
SUNWhea
/usr/include/sys/fs/cachefs_dir.h
/usr/include/sys/fs/cachefs_dlog.h
/usr/include/sys/fs/cachefs_filegrp.h
/usr/include/sys/fs/cachefs_fs.h
/usr/include/sys/fs/cachefs_fscache.h
/usr/include/sys/fs/cachefs_ioctl.h
/usr/include/sys/fs/cachefs_log.h
SUNWckr
For x86/x64
/kernel/fs/amd64/cachefs
/kernel/fs/cachefs
For sparc
/kernel/fs/sparcv9/cachefs
SUNWman
/usr/share/man/man1m/cachefsd.1m
/usr/share/man/man1m/cachefslog.1m
/usr/share/man/man1m/cachefspack.1m
/usr/share/man/man1m/cachefsstat.1m
/usr/share/man/man1m/cachefswssize.1m
/usr/share/man/man1m/fsck_cachefs.1m
/usr/share/man/man1m/mount_cachefs.1m
4.11. Security Impact:
4.12. Dependencies:
5. Reference Documents:
Cachefs PSARC:
http://sac.sfbay/PSARC/1991/042/
http://sac.sfbay/PSARC/1991/042/cfs_design.ps
Cache-only clients
http://sac.eng/PSARC/1993/287/
AutoClient
http://sac.sfbay/PSARC/1999/038/
Autofs explicit support for cachefs
http://sac.sfbay/PSARC/1993/206/
6. Resources and Schedule:
6.1. Projected Availability:
by 23/09/2009
6.2. Cost of Effort:
4 man months
6.3. Cost of Capital Resources:
6.4. Product Approval Committee requested information:
6.4.1. Consolidation or Component Name:
ON
6.4.3. Type of CPT Review and Approval expected:
FastTrack
6.4.4. Project Boundary Conditions:
6.4.5. Is this a necessary project for OEM agreements:
6.4.6. Notes:
6.4.7. Target RTI Date/Release:
6.4.8. Target Code Design Review Date:
6.4.9. Update approval addition:
6.5. ARC review type:
FastTrack
6.6. ARC Exposure:
open
6.6.1. Rationale:
7. Prototype Availability:
7.1. Prototype Availability:
7.2. Prototype Cost:
