I confess that I have a mixed mind about this. On the one hand, getting
rid of code that is unmaintained, or extraordinarily difficult or
expensive to maintain (with little real need) seems like a good idea.
On the other hand, I'm not entirely convinced that the need serviced by
cachefs is no longer relevant. I wonder how many folks still make use
of it over wide area networks, where the network performance is still
just as crummy as it was when cachefs was popular? Recently, I had
tried using it myself to serve up ON tools and gates, and was reasonably
pleased with it, except for some very ugly interactions with autofs,
which I won't go into here, except to say that I'm no longer running it
-- which goes to the point of removing it. (I have personally switched
to using local copies of key data, and bringing over periodic updates
via turbo-bringover. Hg will eliminate even much of that.)
Not architectural, but do we have any data showing that NFSv4 offers
enough in the way of caching and to eliminate the need for cachefs even
over slow data links? (And, do we have any data w.r.t. the migration
of sites from NFSv2/v3 to NFSv4?)
- Garrett
Daniel Hain wrote:
> 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:
>
>
>
>
>
