From Daniel.Hain@sun.com Mon Jul 28 11:46:37 2008 Received: from sunmail5.uk.sun.com (sunmail5.UK.Sun.COM [129.156.85.165]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id m6SIkbP6027033 for ; Mon, 28 Jul 2008 11:46:37 -0700 (PDT) Received: from nwk-avmta-2.sfbay.sun.com (nwk-avmta-2.SFBay.Sun.COM [129.145.155.6]) by sunmail5.uk.sun.com (8.13.8+Sun/8.13.8/ENSMAIL,v2.2) with ESMTP id m6SIkD64021448 for <@sunmail2sca.sfbay.sun.com:PSARC-ext@sun.com>; Mon, 28 Jul 2008 19:46:36 +0100 (BST) Received: from pmxchannel-daemon.nwk-avmta-2.sfbay.sun.com by nwk-avmta-2.sfbay.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0K4Q00K0NC5NAI00@nwk-avmta-2.sfbay.sun.com> for PSARC-ext@sun.com (ORCPT PSARC-ext@Sun.Com); Mon, 28 Jul 2008 11:46:35 -0700 (PDT) Received: from sca-es-mail-1.sun.com ([192.18.43.132]) by nwk-avmta-2.sfbay.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0K4Q00HD4C5NB770@nwk-avmta-2.sfbay.sun.com> for PSARC-ext@sun.com (ORCPT PSARC-ext@Sun.Com); Mon, 28 Jul 2008 11:46:35 -0700 (PDT) Received: from fe-sfbay-09.sun.com ([192.18.43.129]) by sca-es-mail-1.sun.com (8.13.7+Sun/8.12.9) with ESMTP id m6SIkZjH017776 for ; Mon, 28 Jul 2008 11:46:35 -0700 (PDT) Received: from conversion-daemon.fe-sfbay-09.sun.com by fe-sfbay-09.sun.com (Sun Java System Messaging Server 6.2-8.04 (built Feb 28 2007)) id <0K4Q00K01BSCSN00@fe-sfbay-09.sun.com> (original mail from Daniel.Hain@Sun.COM) for PSARC-ext@Sun.Com (ORCPT PSARC-ext@Sun.Com); Mon, 28 Jul 2008 11:46:35 -0700 (PDT) Received: from [129.153.88.172] by fe-sfbay-09.sun.com (Sun Java System Messaging Server 6.2-8.04 (built Feb 28 2007)) with ESMTPSA id <0K4Q00NFOC5K4PA0@fe-sfbay-09.sun.com> for PSARC-ext@Sun.Com (ORCPT PSARC-ext@Sun.Com); Mon, 28 Jul 2008 11:46:32 -0700 (PDT) Date: Mon, 28 Jul 2008 11:46:52 -0700 From: Daniel Hain Subject: EOF of Cache FileSystem (cachefs) [PSARC/2008/478 FastTrack timeout 08/04/2008] Sender: Daniel.Hain@sun.com To: PSARC-ext@sun.com Cc: Nagakiran.Rajashekar@sun.com Message-id: <488E141C.9060003@sun.com> MIME-version: 1.0 Content-type: text/plain; format=flowed; charset=ISO-8859-1 Content-transfer-encoding: 7BIT X-PMX-Version: 5.4.1.325704 User-Agent: Thunderbird 2.0.0.12 (X11/20080310) Status: RO Content-Length: 14905 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 2008 Sun Microsystems 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@SUN.COM, Lisa.M.Chatham@SUN.COM 1.5.2. Responsible Engineer: Nagakiran.Rajashekar@SUN.COM 1.5.3. Marketing Manager: Kamal.Varma@SUN.COM 1.5.4. Interest List: cachefs-eof-discuss@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: From dwc@spartan.eng.sun.com Mon Jul 28 12:17:14 2008 Received: from sunmail3mpk.sfbay.sun.com (sunmail3mpk.SFBay.Sun.COM [129.146.11.52]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id m6SJHEEt027970 for ; Mon, 28 Jul 2008 12:17:14 -0700 (PDT) Received: from brm-avmta-1.central.sun.com (brm-avmta-1.Central.Sun.COM [129.147.4.11]) by sunmail3mpk.sfbay.sun.com (8.13.7+Sun/8.13.7/ENSMAIL,v2.2) with ESMTP id m6SJH1Tr013830 for <@sunmail2sca.sfbay.sun.com:PSARC-ext@sun.com>; Mon, 28 Jul 2008 12:17:13 -0700 (PDT) Received: from pmxchannel-daemon.brm-avmta-1.central.sun.com by brm-avmta-1.central.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0K4Q0081BDKPNA00@brm-avmta-1.central.sun.com> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Mon, 28 Jul 2008 13:17:13 -0600 (MDT) Received: from dm-eng-02.sfbay.sun.com ([129.146.11.32]) by brm-avmta-1.central.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0K4Q00JH5DKO3TC0@brm-avmta-1.central.sun.com> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Mon, 28 Jul 2008 13:17:13 -0600 (MDT) Received: from spartan.eng.sun.com (spartan.SFBay.Sun.COM [129.146.226.64]) by dm-eng-02.sfbay.sun.com (8.13.8+Sun/8.13.8/ENSMAIL,v2.2) with ESMTP id m6SJHBEr054660; Mon, 28 Jul 2008 12:17:11 -0700 (PDT) Received: from spartan.eng.sun.com (localhost [127.0.0.1]) by spartan.eng.sun.com (8.13.7+Sun/8.13.7) with ESMTP id m6SJ9faX022206; Mon, 28 Jul 2008 12:09:41 -0700 (PDT) Received: (from dwc@localhost) by spartan.eng.sun.com (8.13.7+Sun/8.13.7/Submit) id m6SJ9fO5022205; Mon, 28 Jul 2008 12:09:41 -0700 (PDT) Date: Mon, 28 Jul 2008 12:09:41 -0700 (PDT) From: Don Cragun Subject: Re: EOF of Cache FileSystem (cachefs) [PSARC/2008/478 FastTrack timeout 08/04/2008] To: Daniel.Hain@sun.com Cc: Nagakiran.Rajashekar@sun.com, PSARC-ext@sun.com Message-id: <200807281909.m6SJ9fO5022205@spartan.eng.sun.com> Content-transfer-encoding: 7BIT X-PMX-Version: 5.4.1.325704 Status: RO Content-Length: 64 What release binding are you requesting for this case? - Don From gdamore@sun.com Mon Jul 28 12:42:36 2008 Received: from newsunmail1brm.central.sun.com (newsunmail1brm.Central.Sun.COM [129.147.62.245]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id m6SJgZFV028207 for ; Mon, 28 Jul 2008 12:42:36 -0700 (PDT) Received: from nwk-avmta-1.SFBay.Sun.COM (nwk-avmta-1.SFBay.Sun.COM [129.146.11.74]) by newsunmail1brm.central.sun.com (8.13.7+Sun/8.13.7/ENSMAIL,v2.2) with ESMTP id m6SJgYuN050037 for <@sunmail2sca.sfbay.sun.com:PSARC-ext@sun.com>; Mon, 28 Jul 2008 13:42:35 -0600 (MDT) Received: from pmxchannel-daemon.nwk-avmta-1.sfbay.Sun.COM by nwk-avmta-1.sfbay.Sun.COM (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0K4Q00903EQZ1O00@nwk-avmta-1.sfbay.Sun.COM> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Mon, 28 Jul 2008 12:42:35 -0700 (PDT) Received: from sca-es-mail-1.sun.com ([192.18.43.132]) by nwk-avmta-1.sfbay.Sun.COM (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0K4Q00I06EQYGNC0@nwk-avmta-1.sfbay.Sun.COM> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Mon, 28 Jul 2008 12:42:34 -0700 (PDT) Received: from fe-sfbay-09.sun.com ([192.18.43.129]) by sca-es-mail-1.sun.com (8.13.7+Sun/8.12.9) with ESMTP id m6SJgYIi024617 for ; Mon, 28 Jul 2008 12:42:34 -0700 (PDT) Received: from conversion-daemon.fe-sfbay-09.sun.com by fe-sfbay-09.sun.com (Sun Java System Messaging Server 6.2-8.04 (built Feb 28 2007)) id <0K4Q00G01EL6R000@fe-sfbay-09.sun.com> (original mail from gdamore@sun.com) for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Mon, 28 Jul 2008 12:42:34 -0700 (PDT) Received: from [10.7.251.172] by fe-sfbay-09.sun.com (Sun Java System Messaging Server 6.2-8.04 (built Feb 28 2007)) with ESMTPSA id <0K4Q00K09EQYP100@fe-sfbay-09.sun.com> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Mon, 28 Jul 2008 12:42:34 -0700 (PDT) Date: Mon, 28 Jul 2008 12:38:05 -0700 From: "Garrett D'Amore" Subject: Re: EOF of Cache FileSystem (cachefs) [PSARC/2008/478 FastTrack timeout 08/04/2008] In-reply-to: <488E141C.9060003@sun.com> Sender: Garrett.Damore@sun.com To: Daniel Hain Cc: PSARC-ext@sun.com, Nagakiran.Rajashekar@sun.com Message-id: <488E201D.1070004@sun.com> MIME-version: 1.0 Content-type: text/plain; format=flowed; charset=ISO-8859-1 Content-transfer-encoding: 7BIT X-PMX-Version: 5.4.1.325704 References: <488E141C.9060003@sun.com> User-Agent: Thunderbird 2.0.0.14 (X11/20080616) Status: RO Content-Length: 16556 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 2008 Sun Microsystems > > 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@SUN.COM, Lisa.M.Chatham@SUN.COM > 1.5.2. Responsible Engineer: > Nagakiran.Rajashekar@SUN.COM > 1.5.3. Marketing Manager: > Kamal.Varma@SUN.COM 1.5.4. Interest List: > cachefs-eof-discuss@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: > > > > > From Darren.Moffat@sun.com Mon Jul 28 13:19:59 2008 Received: from newsunmail1brm.central.sun.com (newsunmail1brm.Central.Sun.COM [129.147.62.245]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id m6SKJxNF029547 for ; Mon, 28 Jul 2008 13:19:59 -0700 (PDT) Received: from nwk-avmta-1.SFBay.Sun.COM (nwk-avmta-1.SFBay.Sun.COM [129.146.11.74]) by newsunmail1brm.central.sun.com (8.13.7+Sun/8.13.7/ENSMAIL,v2.2) with ESMTP id m6SKJujp061180 for <@sunmail2sca.sfbay.sun.com:PSARC-ext@sun.com>; Mon, 28 Jul 2008 14:19:58 -0600 (MDT) Received: from pmxchannel-daemon.nwk-avmta-1.sfbay.Sun.COM by nwk-avmta-1.sfbay.Sun.COM (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0K4Q00C09GHAU800@nwk-avmta-1.sfbay.Sun.COM> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Mon, 28 Jul 2008 13:19:58 -0700 (PDT) Received: from gmp-eb-inf-1.sun.com ([192.18.6.21]) by nwk-avmta-1.sfbay.Sun.COM (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0K4Q00C6DGH9LK00@nwk-avmta-1.sfbay.Sun.COM> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Mon, 28 Jul 2008 13:19:57 -0700 (PDT) Received: from fe-emea-09.sun.com (gmp-eb-lb-2-fe1.eu.sun.com [192.18.6.10]) by gmp-eb-inf-1.sun.com (8.13.7+Sun/8.12.9) with ESMTP id m6SKJuFc021372 for ; Mon, 28 Jul 2008 20:19:56 +0000 (GMT) Received: from conversion-daemon.fe-emea-09.sun.com by fe-emea-09.sun.com (Sun Java System Messaging Server 6.2-8.04 (built Feb 28 2007)) id <0K4Q00G01GGRLS00@fe-emea-09.sun.com> (original mail from Darren.Moffat@Sun.COM) for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Mon, 28 Jul 2008 21:19:56 +0100 (BST) Received: from [129.156.173.21] by fe-emea-09.sun.com (Sun Java System Messaging Server 6.2-8.04 (built Feb 28 2007)) with ESMTPSA id <0K4Q0061PGH73MF0@fe-emea-09.sun.com> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Mon, 28 Jul 2008 21:19:56 +0100 (BST) Date: Mon, 28 Jul 2008 21:19:55 +0100 From: Darren J Moffat Subject: Re: EOF of Cache FileSystem (cachefs) [PSARC/2008/478 FastTrack timeout 08/04/2008] In-reply-to: <488E201D.1070004@sun.com> Sender: Darren.Moffat@sun.com To: "Garrett D'Amore" Cc: Daniel Hain , PSARC-ext@sun.com, Nagakiran.Rajashekar@sun.com Message-id: <488E29EB.5080803@Sun.COM> MIME-version: 1.0 Content-type: text/plain; format=flowed; charset=ISO-8859-1 Content-transfer-encoding: 7BIT X-PMX-Version: 5.4.1.325704 References: <488E141C.9060003@sun.com> <488E201D.1070004@sun.com> User-Agent: Thunderbird 2.0.0.14 (X11/20080630) Status: RO Content-Length: 1050 Personally I agree completely with the EOF of the current implementation, having been directly involved in supporting it in Sun Service and sustaining. However I disagree that we no longer need such functionality. I also find it quite sadly ironic that other operating systems are only now starting to implement something like cachefs just we Solaris is about to pull the rug out from underneath it. See: http://en.wikipedia.org/wiki/CacheFS NFS+CacheFS+Kerberos was a good competitor for AFS if we drop the CacheFS part we only have base NFSv4+Kerberos and IMO that level of caching is not good enough. I believe we need a persistent (ie local disk/ssd) cache integrated with NFSv4 before this EOF can be approved. However if there is business evidence that CacheFS is no longer required functionality (rather than no longer used because it doesn't work with NFSv4 or is buggy) I'd like to see that. Basically from an architecture view point this EOF leaves us with a gap that I think needs to be filled. -- Darren J Moffat From gdamore@sun.com Mon Jul 28 13:36:32 2008 Received: from sunmail5.uk.sun.com (sunmail5.UK.Sun.COM [129.156.85.165]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id m6SKaWP1000691 for ; Mon, 28 Jul 2008 13:36:32 -0700 (PDT) Received: from nwk-avmta-2.sfbay.sun.com (nwk-avmta-2.SFBay.Sun.COM [129.145.155.6]) by sunmail5.uk.sun.com (8.13.8+Sun/8.13.8/ENSMAIL,v2.2) with ESMTP id m6SKaSg3010304 for <@sunmail2sca.sfbay.sun.com:PSARC-ext@sun.com>; Mon, 28 Jul 2008 21:36:31 +0100 (BST) Received: from pmxchannel-daemon.nwk-avmta-2.sfbay.sun.com by nwk-avmta-2.sfbay.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0K4Q0010HH8TLM00@nwk-avmta-2.sfbay.sun.com> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Mon, 28 Jul 2008 13:36:29 -0700 (PDT) Received: from sca-es-mail-1.sun.com ([192.18.43.132]) by nwk-avmta-2.sfbay.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0K4Q00MPXH8TUH20@nwk-avmta-2.sfbay.sun.com> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Mon, 28 Jul 2008 13:36:29 -0700 (PDT) Received: from fe-sfbay-10.sun.com ([192.18.43.129]) by sca-es-mail-1.sun.com (8.13.7+Sun/8.12.9) with ESMTP id m6SKaSWP001359 for ; Mon, 28 Jul 2008 13:36:28 -0700 (PDT) Received: from conversion-daemon.fe-sfbay-10.sun.com by fe-sfbay-10.sun.com (Sun Java System Messaging Server 6.2-8.04 (built Feb 28 2007)) id <0K4Q00I01H354700@fe-sfbay-10.sun.com> (original mail from gdamore@sun.com) for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Mon, 28 Jul 2008 13:36:28 -0700 (PDT) Received: from [10.7.251.172] by fe-sfbay-10.sun.com (Sun Java System Messaging Server 6.2-8.04 (built Feb 28 2007)) with ESMTPSA id <0K4Q00JULH8KC780@fe-sfbay-10.sun.com> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Mon, 28 Jul 2008 13:36:20 -0700 (PDT) Date: Mon, 28 Jul 2008 13:31:51 -0700 From: "Garrett D'Amore" Subject: Re: EOF of Cache FileSystem (cachefs) [PSARC/2008/478 FastTrack timeout 08/04/2008] In-reply-to: <488E29EB.5080803@Sun.COM> Sender: Garrett.Damore@sun.com To: Darren J Moffat Cc: Daniel Hain , PSARC-ext@sun.com, Nagakiran.Rajashekar@sun.com Message-id: <488E2CB7.4020700@sun.com> MIME-version: 1.0 Content-type: text/plain; format=flowed; charset=ISO-8859-1 Content-transfer-encoding: 7BIT X-PMX-Version: 5.4.1.325704 References: <488E141C.9060003@sun.com> <488E201D.1070004@sun.com> <488E29EB.5080803@Sun.COM> User-Agent: Thunderbird 2.0.0.14 (X11/20080616) Status: RO Content-Length: 1885 I confess that I didn't realize we lacked client side caching in our NFSv4. I thought client side caching was one of the significant benefits that NFSv4 brought to the table (mainly to compete with the likes of AFS and DFS). If we don't have client side caching in NFSv4, then I too worry that the loss of functionality will leave us with a potentially significant architectural hole. Again, for folks on local networks, the network may not be the bottleneck, but with VPNs and similar technologies increasing the global reach of corporate networks, I think there is still a real business case for client side caching. So, please either provide information as to how this gap will be filled, or evidence as to why it isn't necessary. -- Garrett Darren J Moffat wrote: > Personally I agree completely with the EOF of the current > implementation, having been directly involved in supporting it in Sun > Service and sustaining. > > > However I disagree that we no longer need such functionality. I also > find it quite sadly ironic that other operating systems are only now > starting to implement something like cachefs just we Solaris is about > to pull the rug out from underneath it. > > See: http://en.wikipedia.org/wiki/CacheFS > > NFS+CacheFS+Kerberos was a good competitor for AFS if we drop the > CacheFS part we only have base NFSv4+Kerberos and IMO that level of > caching is not good enough. > > I believe we need a persistent (ie local disk/ssd) cache integrated > with NFSv4 before this EOF can be approved. However if there is > business evidence that CacheFS is no longer required functionality > (rather than no longer used because it doesn't work with NFSv4 or is > buggy) I'd like to see that. > > Basically from an architecture view point this EOF leaves us with a > gap that I think needs to be filled. > > -- > Darren J Moffat From Daniel.Hain@Sun.COM Mon Jul 28 13:36:40 2008 Received: from newsunmail1brm.central.sun.com (newsunmail1brm.Central.Sun.COM [129.147.62.245]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id m6SKadPq000727 for ; Mon, 28 Jul 2008 13:36:40 -0700 (PDT) Received: from brm-avmta-1.central.sun.com (brm-avmta-1.Central.Sun.COM [129.147.4.11]) by newsunmail1brm.central.sun.com (8.13.7+Sun/8.13.7/ENSMAIL,v2.2) with ESMTP id m6SKadFT000737 for <@sunmail2sca.sfbay.sun.com:PSARC-ext@sun.com>; Mon, 28 Jul 2008 14:36:39 -0600 (MDT) Received: from pmxchannel-daemon.brm-avmta-1.central.sun.com by brm-avmta-1.central.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0K4Q00E09H934D00@brm-avmta-1.central.sun.com> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Mon, 28 Jul 2008 14:36:39 -0600 (MDT) Received: from sca-es-mail-1.sun.com ([192.18.43.132]) by brm-avmta-1.central.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0K4Q00BCZH92SI30@brm-avmta-1.central.sun.com> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Mon, 28 Jul 2008 14:36:38 -0600 (MDT) Received: from fe-sfbay-10.sun.com ([192.18.43.129]) by sca-es-mail-1.sun.com (8.13.7+Sun/8.12.9) with ESMTP id m6SKacgQ001369 for ; Mon, 28 Jul 2008 13:36:38 -0700 (PDT) Received: from conversion-daemon.fe-sfbay-10.sun.com by fe-sfbay-10.sun.com (Sun Java System Messaging Server 6.2-8.04 (built Feb 28 2007)) id <0K4Q00301G02T600@fe-sfbay-10.sun.com> (original mail from Daniel.Hain@Sun.COM) for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Mon, 28 Jul 2008 13:36:38 -0700 (PDT) Received: from [129.153.88.172] by fe-sfbay-10.sun.com (Sun Java System Messaging Server 6.2-8.04 (built Feb 28 2007)) with ESMTPSA id <0K4Q00JW6H8QC780@fe-sfbay-10.sun.com> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Mon, 28 Jul 2008 13:36:26 -0700 (PDT) Date: Mon, 28 Jul 2008 13:36:46 -0700 From: Daniel Hain Subject: Re: EOF of Cache FileSystem (cachefs) [PSARC/2008/478 FastTrack timeout 08/04/2008] In-reply-to: <200807281909.m6SJ9fO5022205@spartan.eng.sun.com> Sender: Daniel.Hain@Sun.COM To: PSARC-ext@Sun.COM Cc: Nagakiran.Rajashekar@Sun.COM Message-id: <488E2DDE.9000809@sun.com> MIME-version: 1.0 Content-type: text/plain; format=flowed; charset=ISO-8859-1 Content-transfer-encoding: 7BIT X-PMX-Version: 5.4.1.325704 References: <200807281909.m6SJ9fO5022205@spartan.eng.sun.com> User-Agent: Thunderbird 2.0.0.12 (X11/20080310) Status: RO Content-Length: 693 Don Cragun wrote: > What release binding are you requesting for this case? > > - Don > > Looking for minor release binding. -- Dan Hain Solaris Revenue Product Engineering (RPE) From Spencer.Shepler@sun.com Mon Jul 28 15:09:39 2008 Received: from sunmail2sca.sfbay.sun.com (sunmail2sca.SFBay.Sun.COM [129.145.155.234]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id m6SM9dJB005162 for ; Mon, 28 Jul 2008 15:09:39 -0700 (PDT) Received: from nwk-avmta-2.sfbay.sun.com (nwk-avmta-2.SFBay.Sun.COM [129.145.155.6]) by sunmail2sca.sfbay.sun.com (8.13.7+Sun/8.13.7/ENSMAIL,v2.2) with ESMTP id m6SM9bku008033 for <@sunmail2sca.sfbay.sun.com:PSARC-ext@sun.com>; Mon, 28 Jul 2008 15:09:39 -0700 (PDT) Received: from pmxchannel-daemon.nwk-avmta-2.sfbay.sun.com by nwk-avmta-2.sfbay.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0K4Q0050HLK2MJ00@nwk-avmta-2.sfbay.sun.com> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Mon, 28 Jul 2008 15:09:38 -0700 (PDT) Received: from brmea-mail-2.sun.com ([192.18.98.43]) by nwk-avmta-2.sfbay.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0K4Q00M50LK1UP90@nwk-avmta-2.sfbay.sun.com> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Mon, 28 Jul 2008 15:09:37 -0700 (PDT) Received: from fe-amer-10.sun.com ([192.18.109.80]) by brmea-mail-2.sun.com (8.13.6+Sun/8.12.9) with ESMTP id m6SM9bFU020204 for ; Mon, 28 Jul 2008 22:09:37 +0000 (GMT) Received: from conversion-daemon.mail-amer.sun.com by mail-amer.sun.com (Sun Java System Messaging Server 6.2-8.04 (built Feb 28 2007)) id <0K4Q00701L2MVT00@mail-amer.sun.com> (original mail from Spencer.Shepler@Sun.COM) for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Mon, 28 Jul 2008 16:09:37 -0600 (MDT) Received: from [10.1.232.92] by mail-amer.sun.com (Sun Java System Messaging Server 6.2-8.04 (built Feb 28 2007)) with ESMTPSA id <0K4Q006J7LJR8ZA0@mail-amer.sun.com> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Mon, 28 Jul 2008 16:09:28 -0600 (MDT) Date: Mon, 28 Jul 2008 17:09:28 -0500 From: Spencer Shepler Subject: Re: EOF of Cache FileSystem (cachefs) [PSARC/2008/478 FastTrack timeout 08/04/2008] In-reply-to: <488E29EB.5080803@Sun.COM> Sender: Spencer.Shepler@sun.com To: Darren J Moffat Cc: "Garrett D'Amore" , Daniel Hain , Nagakiran.Rajashekar@sun.com, PSARC-ext@sun.com Message-id: MIME-version: 1.0 X-Mailer: Apple Mail (2.753.1) Content-type: text/plain; format=flowed; delsp=yes; charset=US-ASCII Content-transfer-encoding: 7BIT X-PMX-Version: 5.4.1.325704 References: <488E141C.9060003@sun.com> <488E201D.1070004@sun.com> <488E29EB.5080803@Sun.COM> Status: RO Content-Length: 1707 On Jul 28, 2008, at 3:19 PM, Darren J Moffat wrote: > Personally I agree completely with the EOF of the current > implementation, having been directly involved in supporting it in Sun > Service and sustaining. > > > However I disagree that we no longer need such functionality. I also > find it quite sadly ironic that other operating systems are only now > starting to implement something like cachefs just we Solaris is > about to > pull the rug out from underneath it. > > See: http://en.wikipedia.org/wiki/CacheFS > > NFS+CacheFS+Kerberos was a good competitor for AFS if we drop the > CacheFS part we only have base NFSv4+Kerberos and IMO that level of > caching is not good enough. > > I believe we need a persistent (ie local disk/ssd) cache integrated > with > NFSv4 before this EOF can be approved. However if there is business > evidence that CacheFS is no longer required functionality (rather than > no longer used because it doesn't work with NFSv4 or is buggy) I'd > like > to see that. > > Basically from an architecture view point this EOF leaves us with a > gap > that I think needs to be filled. It needs to be filled but what percentage of users would make use of it is the real question. Even with a gap, my opinion is that cachefs should be removed. This gap can be fulfilled with a carefully targeted opensolaris project to enhance the NFS client. My suggestion would be that the ideas (and even some ofthe code) from the l2arc work would be built directly into the NFS client (not a generic solution as in cachefs) and done in very simple terms with very simple assumptions; this will service the 80/20 rule for those users that can truly find it useful. Spencer From Nicolas.Williams@sun.com Mon Jul 28 15:18:01 2008 Received: from sunmail2sca.sfbay.sun.com (sunmail2sca.SFBay.Sun.COM [129.145.155.234]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id m6SMI0hF005351 for ; Mon, 28 Jul 2008 15:18:01 -0700 (PDT) Received: from nwk-avmta-2.sfbay.sun.com (nwk-avmta-2.SFBay.Sun.COM [129.145.155.6]) by sunmail2sca.sfbay.sun.com (8.13.7+Sun/8.13.7/ENSMAIL,v2.2) with ESMTP id m6SMHuaK009793; Mon, 28 Jul 2008 15:17:57 -0700 (PDT) Received: from pmxchannel-daemon.nwk-avmta-2.sfbay.sun.com by nwk-avmta-2.sfbay.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0K4Q00507LXWZD00@nwk-avmta-2.sfbay.sun.com>; Mon, 28 Jul 2008 15:17:56 -0700 (PDT) Received: from binky.Central.Sun.COM ([129.153.128.104]) by nwk-avmta-2.sfbay.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0K4Q00MLGLXWUP90@nwk-avmta-2.sfbay.sun.com>; Mon, 28 Jul 2008 15:17:56 -0700 (PDT) Received: from binky.Central.Sun.COM (localhost [127.0.0.1]) by binky.Central.Sun.COM (8.14.1+Sun/8.14.1) with ESMTP id m6SMHWFo004666; Mon, 28 Jul 2008 17:17:50 -0500 (CDT) Received: (from nw141292@localhost) by binky.Central.Sun.COM (8.14.1+Sun/8.14.1/Submit) id m6SMHWKn004665; Mon, 28 Jul 2008 17:17:32 -0500 (CDT) Date: Mon, 28 Jul 2008 17:17:32 -0500 From: Nicolas Williams Subject: Re: EOF of Cache FileSystem (cachefs) [PSARC/2008/478 FastTrack timeout 08/04/2008] In-reply-to: <488E2CB7.4020700@sun.com> To: "Garrett D'Amore" Cc: Darren J Moffat , Daniel Hain , PSARC-ext@sun.com, Nagakiran.Rajashekar@sun.com Mail-followup-to: Garrett D'Amore , Darren J Moffat , Daniel Hain , PSARC-ext@Sun.COM, Nagakiran.Rajashekar@Sun.COM Message-id: <20080728221732.GA25547@Sun.COM> MIME-version: 1.0 Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7BIT Content-disposition: inline X-PMX-Version: 5.4.1.325704 References: <488E141C.9060003@sun.com> <488E201D.1070004@sun.com> <488E29EB.5080803@Sun.COM> <488E2CB7.4020700@sun.com> X-Authentication-warning: binky.Central.Sun.COM: nw141292 set sender to Nicolas.Williams@sun.com using -f User-Agent: Mutt/1.5.7i Status: RO Content-Length: 967 On Mon, Jul 28, 2008 at 01:31:51PM -0700, Garrett D'Amore wrote: > I confess that I didn't realize we lacked client side caching in our > NFSv4. I thought client side caching was one of the significant > benefits that NFSv4 brought to the table (mainly to compete with the > likes of AFS and DFS). Let's be precise. The NFSv4 client caches plenty, just not on long-term local storage (which is what cachefs was for). > If we don't have client side caching in NFSv4, then I too worry that the > loss of functionality will leave us with a potentially significant > architectural hole. It's a small gap. I think where it really matters one might use ZFS with iSCSI vdevs and a local L2ARC device. > Again, for folks on local networks, the network may not be the > bottleneck, but with VPNs and similar technologies increasing the global > reach of corporate networks, I think there is still a real business case > for client side caching. Yes. Nico -- From gdamore@sun.com Mon Jul 28 15:43:46 2008 Received: from sunmail4.singapore.sun.com (sunmail4.Singapore.Sun.COM [129.158.71.19]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id m6SMhjM2006607 for ; Mon, 28 Jul 2008 15:43:46 -0700 (PDT) Received: from nwk-avmta-1.SFBay.Sun.COM (nwk-avmta-1.SFBay.Sun.COM [129.146.11.74]) by sunmail4.singapore.sun.com (8.13.4+Sun/8.13.3/ENSMAIL,v2.2) with ESMTP id m6SMhXYH010872 for <@sunmail2sca.sfbay.sun.com:PSARC-ext@sun.com>; Tue, 29 Jul 2008 06:43:42 +0800 (SGT) Received: from pmxchannel-daemon.nwk-avmta-1.sfbay.Sun.COM by nwk-avmta-1.sfbay.Sun.COM (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0K4Q00505N4SGN00@nwk-avmta-1.sfbay.Sun.COM> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Mon, 28 Jul 2008 15:43:40 -0700 (PDT) Received: from sca-es-mail-1.sun.com ([192.18.43.132]) by nwk-avmta-1.sfbay.Sun.COM (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0K4Q00COIN4RLMB0@nwk-avmta-1.sfbay.Sun.COM> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Mon, 28 Jul 2008 15:43:40 -0700 (PDT) Received: from fe-sfbay-09.sun.com ([192.18.43.129]) by sca-es-mail-1.sun.com (8.13.7+Sun/8.12.9) with ESMTP id m6SMhdug016798 for ; Mon, 28 Jul 2008 15:43:39 -0700 (PDT) Received: from conversion-daemon.fe-sfbay-09.sun.com by fe-sfbay-09.sun.com (Sun Java System Messaging Server 6.2-8.04 (built Feb 28 2007)) id <0K4Q00401N497500@fe-sfbay-09.sun.com> (original mail from gdamore@sun.com) for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Mon, 28 Jul 2008 15:43:39 -0700 (PDT) Received: from [10.7.251.172] by fe-sfbay-09.sun.com (Sun Java System Messaging Server 6.2-8.04 (built Feb 28 2007)) with ESMTPSA id <0K4Q0062SN4Q2Q80@fe-sfbay-09.sun.com> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Mon, 28 Jul 2008 15:43:39 -0700 (PDT) Date: Mon, 28 Jul 2008 15:39:10 -0700 From: "Garrett D'Amore" Subject: Re: EOF of Cache FileSystem (cachefs) [PSARC/2008/478 FastTrack timeout 08/04/2008] In-reply-to: <20080728221732.GA25547@Sun.COM> Sender: Garrett.Damore@sun.com To: "Garrett D'Amore" , Darren J Moffat , Daniel Hain , PSARC-ext@sun.com, Nagakiran.Rajashekar@sun.com Message-id: <488E4A8E.8090406@sun.com> MIME-version: 1.0 Content-type: text/plain; format=flowed; charset=ISO-8859-1 Content-transfer-encoding: 7BIT X-PMX-Version: 5.4.1.325704 References: <488E141C.9060003@sun.com> <488E201D.1070004@sun.com> <488E29EB.5080803@Sun.COM> <488E2CB7.4020700@sun.com> <20080728221732.GA25547@Sun.COM> User-Agent: Thunderbird 2.0.0.14 (X11/20080616) Status: RO Content-Length: 2502 Nicolas Williams wrote: > On Mon, Jul 28, 2008 at 01:31:51PM -0700, Garrett D'Amore wrote: > >> I confess that I didn't realize we lacked client side caching in our >> NFSv4. I thought client side caching was one of the significant >> benefits that NFSv4 brought to the table (mainly to compete with the >> likes of AFS and DFS). >> > > Let's be precise. The NFSv4 client caches plenty, just not on long-term > local storage (which is what cachefs was for). > How much data is cached by NFSv4? With cachefs you could set up fairly large (100's or 1000's of MB) local cache, so for data that didn't change often you almost never had to go to the network for anything (other than a stat()-like check.) Its a shame to lose the entire cache on a reboot, but potentially this might be acceptable for some use cases. (For others, its clearly inferior -- think of the mobile laptop that gets powered off frequently.... or even the power conscious desktop user. Even Suspend-to-RAM requires some power, and we don't have universal support for it everywhere.) > >> If we don't have client side caching in NFSv4, then I too worry that the >> loss of functionality will leave us with a potentially significant >> architectural hole. >> > > It's a small gap. > > I think where it really matters one might use ZFS with iSCSI vdevs and a > local L2ARC device. > An interesting idea. I am not too familiar with iSCSI, but don't you need an iSCSI target? I'm not sure, is iSCSI seeing deployment outside of the data center? (NFS is designed to support concurrent network use and reasonably handles multiple "intiators". How does iSCSI deal with such a situation?) I'd be happy to see a whitepaper or some kind of transition document with the case, describing (ideally in terms a customer should be able to understand) how to transition from cachefs to some other strategy (iSCSI, NFSv4, whatever). I don't know how to make the same functionality (NFS like) work with iSCSI, but I'll chalk that up to my own ignorance rather than any deficiency in iSCSI. It would be nice to see a commitment to closing any remaining gap as much as possible, perhaps by further development of NFSv4 -- as others have suggested. As a final note, I do recall that cachefs was supposed to be generic for things like cdroms, etc. I do agree with the proposal that cachefs like behavior for anything *other than NFS* is probably not terribly interesting. -- Garrett From Nicolas.Williams@sun.com Mon Jul 28 15:50:13 2008 Received: from sunmail3mpk.sfbay.sun.com (sunmail3mpk.SFBay.Sun.COM [129.146.11.52]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id m6SMoDu0007195 for ; Mon, 28 Jul 2008 15:50:13 -0700 (PDT) Received: from brm-avmta-1.central.sun.com (brm-avmta-1.Central.Sun.COM [129.147.4.11]) by sunmail3mpk.sfbay.sun.com (8.13.7+Sun/8.13.7/ENSMAIL,v2.2) with ESMTP id m6SMo3Iu019631; Mon, 28 Jul 2008 15:50:09 -0700 (PDT) Received: from pmxchannel-daemon.brm-avmta-1.central.sun.com by brm-avmta-1.central.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0K4Q00005NFJN200@brm-avmta-1.central.sun.com>; Mon, 28 Jul 2008 16:50:08 -0600 (MDT) Received: from binky.Central.Sun.COM ([129.153.128.104]) by brm-avmta-1.central.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0K4Q00BPONFJSRC0@brm-avmta-1.central.sun.com>; Mon, 28 Jul 2008 16:50:07 -0600 (MDT) Received: from binky.Central.Sun.COM (localhost [127.0.0.1]) by binky.Central.Sun.COM (8.14.1+Sun/8.14.1) with ESMTP id m6SMo7eS004713; Mon, 28 Jul 2008 17:50:07 -0500 (CDT) Received: (from nw141292@localhost) by binky.Central.Sun.COM (8.14.1+Sun/8.14.1/Submit) id m6SMo72d004712; Mon, 28 Jul 2008 17:50:07 -0500 (CDT) Date: Mon, 28 Jul 2008 17:50:07 -0500 From: Nicolas Williams Subject: Re: EOF of Cache FileSystem (cachefs) [PSARC/2008/478 FastTrack timeout 08/04/2008] In-reply-to: <488E4A8E.8090406@sun.com> To: "Garrett D'Amore" Cc: Darren J Moffat , Daniel Hain , PSARC-ext@sun.com, Nagakiran.Rajashekar@sun.com Mail-followup-to: Garrett D'Amore , Darren J Moffat , Daniel Hain , PSARC-ext@sun.com, Nagakiran.Rajashekar@sun.com Message-id: <20080728225006.GE25547@Sun.COM> MIME-version: 1.0 Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7BIT Content-disposition: inline X-PMX-Version: 5.4.1.325704 References: <488E141C.9060003@sun.com> <488E201D.1070004@sun.com> <488E29EB.5080803@Sun.COM> <488E2CB7.4020700@sun.com> <20080728221732.GA25547@Sun.COM> <488E4A8E.8090406@sun.com> X-Authentication-warning: binky.Central.Sun.COM: nw141292 set sender to Nicolas.Williams@sun.com using -f User-Agent: Mutt/1.5.7i Status: RO Content-Length: 2137 On Mon, Jul 28, 2008 at 03:39:10PM -0700, Garrett D'Amore wrote: > Nicolas Williams wrote: > >On Mon, Jul 28, 2008 at 01:31:51PM -0700, Garrett D'Amore wrote: > > > >>I confess that I didn't realize we lacked client side caching in our > >>NFSv4. I thought client side caching was one of the significant > >>benefits that NFSv4 brought to the table (mainly to compete with the > >>likes of AFS and DFS). > >> > > > >Let's be precise. The NFSv4 client caches plenty, just not on long-term > >local storage (which is what cachefs was for). > > > How much data is cached by NFSv4? With cachefs you could set up > fairly large (100's or 1000's of MB) local cache, so for data that > didn't change often you almost never had to go to the network for > anything (other than a stat()-like check.) NFSv4's cache is limited by RAM. It goes away on reboot. > >It's a small gap. > > > >I think where it really matters one might use ZFS with iSCSI vdevs and a > >local L2ARC device. > > An interesting idea. I am not too familiar with iSCSI, but don't you > need an iSCSI target? I'm not sure, is iSCSI seeing deployment outside > of the data center? (NFS is designed to support concurrent network use > and reasonably handles multiple "intiators". How does iSCSI deal with > such a situation?) Right. If the filesystems in question are read-only I think you can share a target as read-only to many initiators. > It would be nice to see a commitment to closing any remaining gap as > much as possible, perhaps by further development of NFSv4 -- as others > have suggested. > > As a final note, I do recall that cachefs was supposed to be generic for > things like cdroms, etc. I do agree with the proposal that cachefs like > behavior for anything *other than NFS* is probably not terribly interesting. I don't. cachefs like behaviour could be useful for CIFS as well (and some day WebDAV too, why not, and maybe the AFS community would use the infrastructure if available). The problem with cachefs is that it needs to be a service provided to filesystems that filesystems must use explicitly. Nico -- From kmcdonald@egenera.com Mon Jul 28 16:10:05 2008 Received: from sunmail4.singapore.sun.com (sunmail4.Singapore.Sun.COM [129.158.71.19]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id m6SNA4As007912 for ; Mon, 28 Jul 2008 16:10:04 -0700 (PDT) Received: from nwk-avmta-1.SFBay.Sun.COM (nwk-avmta-1.SFBay.Sun.COM [129.146.11.74]) by sunmail4.singapore.sun.com (8.13.4+Sun/8.13.3/ENSMAIL,v2.2) with ESMTP id m6SN9pnN019728; Tue, 29 Jul 2008 07:09:58 +0800 (SGT) Received: from pmxchannel-daemon.nwk-avmta-1.sfbay.Sun.COM by nwk-avmta-1.sfbay.Sun.COM (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0K4Q0081XOCLM900@nwk-avmta-1.sfbay.Sun.COM>; Mon, 28 Jul 2008 16:09:57 -0700 (PDT) Received: from brmea-mail-1.sun.com ([192.18.98.31]) by nwk-avmta-1.sfbay.Sun.COM (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0K4Q00CTIOBELMD0@nwk-avmta-1.sfbay.Sun.COM>; Mon, 28 Jul 2008 16:09:14 -0700 (PDT) Received: from relay15i.sun.com (ip125.net129179-4.block1.us.syntegra.com [129.179.4.125]) by brmea-mail-1.sun.com (8.13.6+Sun/8.12.9) with ESMTP id m6SN7xb2016600; Mon, 28 Jul 2008 23:09:14 +0000 (GMT) Received: from mmp14es.mmp.us.syntegra.com ([160.41.208.14] [160.41.208.14]) by relay15i.sun.com with ESMTP id BT-MMP-402710; Mon, 28 Jul 2008 23:09:13 +0000 (Z) Received: from relay11i.sun.com (relay11i.sun.com [129.179.4.121]) by mmp14es.mmp.us.syntegra.com with ESMTP id BT-MMP-119249; Mon, 28 Jul 2008 23:09:13 +0000 (Z) Received: from webaccess.egenera.com ([63.139.209.15] [63.139.209.15]) by relay1i.sun.com with ESMTP id BT-MMP-2352267; Mon, 28 Jul 2008 23:09:13 +0000 (Z) Received: from [10.50.0.212] ([10.50.0.212]) by webaccess.egenera.com over TLS secured channel with Microsoft SMTPSVC(6.0.3790.3959); Mon, 28 Jul 2008 19:10:51 -0400 Date: Mon, 28 Jul 2008 19:10:03 -0400 From: Kyle McDonald Subject: Re: EOF of Cache FileSystem (cachefs) [PSARC/2008/478 FastTrack timeout 08/04/2008] In-reply-to: <20080728225006.GE25547@Sun.COM> To: "Garrett D'Amore" , Darren J Moffat , Daniel Hain , PSARC-ext@sun.com, Nagakiran.Rajashekar@sun.com Message-id: <488E51CB.9060507@Egenera.COM> MIME-version: 1.0 Content-type: text/plain; charset=ISO-8859-1; format=flowed Content-transfer-encoding: 7BIT X-PMX-Version: 5.4.1.325704 X-Brightmail-Tracker: AAAAAA== X-Antispam: No, score=0.0/5.0, scanned in 0.069sec at (localhost [127.0.0.1]) by smf-spamd v1.3.1 - http://smfs.sf.net/ References: <488E141C.9060003@sun.com> <488E201D.1070004@sun.com> <488E29EB.5080803@Sun.COM> <488E2CB7.4020700@sun.com> <20080728221732.GA25547@Sun.COM> <488E4A8E.8090406@sun.com> <20080728225006.GE25547@Sun.COM> User-Agent: Thunderbird 2.0.0.16 (Windows/20080708) X-OriginalArrivalTime: 28 Jul 2008 23:10:51.0410 (UTC) FILETIME=[2DB71F20:01C8F107] Status: RO Content-Length: 2501 Nicolas Williams wrote: > On Mon, Jul 28, 2008 at 03:39:10PM -0700, Garrett D'Amore wrote: > >> Nicolas Williams wrote: >> >>> On Mon, Jul 28, 2008 at 01:31:51PM -0700, Garrett D'Amore wrote: >>> >>> >>>> I confess that I didn't realize we lacked client side caching in our >>>> NFSv4. I thought client side caching was one of the significant >>>> benefits that NFSv4 brought to the table (mainly to compete with the >>>> likes of AFS and DFS). >>>> >>>> >>> Let's be precise. The NFSv4 client caches plenty, just not on long-term >>> local storage (which is what cachefs was for). >>> >>> >> How much data is cached by NFSv4? With cachefs you could set up >> fairly large (100's or 1000's of MB) local cache, so for data that >> didn't change often you almost never had to go to the network for >> anything (other than a stat()-like check.) >> > > NFSv4's cache is limited by RAM. It goes away on reboot. > > >>> It's a small gap. >>> >>> I think where it really matters one might use ZFS with iSCSI vdevs and a >>> local L2ARC device. >>> >> An interesting idea. I am not too familiar with iSCSI, but don't you >> need an iSCSI target? I'm not sure, is iSCSI seeing deployment outside >> of the data center? (NFS is designed to support concurrent network use >> and reasonably handles multiple "intiators". How does iSCSI deal with >> such a situation?) >> > > Right. If the filesystems in question are read-only I think you can > share a target as read-only to many initiators. > > But you suggested using it in ZFS with a local L2ARC. Unless I've missed something, I don't think you can share devices (iSCSI or not) between different ZFS's on different hosts. Can you? -Kyle >> It would be nice to see a commitment to closing any remaining gap as >> much as possible, perhaps by further development of NFSv4 -- as others >> have suggested. >> >> As a final note, I do recall that cachefs was supposed to be generic for >> things like cdroms, etc. I do agree with the proposal that cachefs like >> behavior for anything *other than NFS* is probably not terribly interesting. >> > > I don't. cachefs like behaviour could be useful for CIFS as well (and > some day WebDAV too, why not, and maybe the AFS community would use the > infrastructure if available). > > The problem with cachefs is that it needs to be a service provided to > filesystems that filesystems must use explicitly. > > Nico > From kmcdonald@egenera.com Mon Jul 28 16:16:23 2008 Received: from sunmail2sca.sfbay.sun.com (sunmail2sca.SFBay.Sun.COM [129.145.155.234]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id m6SNGN7J007949 for ; Mon, 28 Jul 2008 16:16:23 -0700 (PDT) Received: from nwk-avmta-1.SFBay.Sun.COM (nwk-avmta-1.SFBay.Sun.COM [129.146.11.74]) by sunmail2sca.sfbay.sun.com (8.13.7+Sun/8.13.7/ENSMAIL,v2.2) with ESMTP id m6SNGIWd024732; Mon, 28 Jul 2008 16:16:19 -0700 (PDT) Received: from pmxchannel-daemon.nwk-avmta-1.sfbay.Sun.COM by nwk-avmta-1.sfbay.Sun.COM (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0K4Q00917ON6CU00@nwk-avmta-1.sfbay.Sun.COM>; Mon, 28 Jul 2008 16:16:18 -0700 (PDT) Received: from sca-ea-mail-4.sun.com ([192.18.43.22]) by nwk-avmta-1.sfbay.Sun.COM (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0K4Q00C1OON5LKF0@nwk-avmta-1.sfbay.Sun.COM>; Mon, 28 Jul 2008 16:16:17 -0700 (PDT) Received: from relay24.sun.com (relay24.sun.com [192.12.251.74] (may be forged)) by sca-ea-mail-4.sun.com (8.13.6+Sun/8.12.9) with ESMTP id m6SNA3PP014993; Mon, 28 Jul 2008 23:16:17 +0000 (GMT) Received: from mms22es.mms.us.syntegra.com ([150.143.232.30] [150.143.232.30]) by relay24i.sun.com with ESMTP id BT-MMP-582912; Mon, 28 Jul 2008 23:16:16 +0000 (Z) Received: from relay23.sun.com (relay23.sun.com [192.12.251.54]) by mms22es.mms.us.syntegra.com with ESMTP id BT-MMP-18632271; Mon, 28 Jul 2008 23:16:16 +0000 (Z) Received: from webaccess.egenera.com ([63.139.209.15] [63.139.209.15]) by relay23i.sun.com with ESMTP id BT-MMP-9388139; Mon, 28 Jul 2008 23:16:16 +0000 (Z) Received: from [10.50.0.212] ([10.50.0.212]) by webaccess.egenera.com over TLS secured channel with Microsoft SMTPSVC(6.0.3790.3959); Mon, 28 Jul 2008 19:17:54 -0400 Date: Mon, 28 Jul 2008 19:17:06 -0400 From: Kyle McDonald Subject: Re: EOF of Cache FileSystem (cachefs) [PSARC/2008/478 FastTrack timeout 08/04/2008] In-reply-to: <20080728225006.GE25547@Sun.COM> To: "Garrett D'Amore" , Darren J Moffat , Daniel Hain , PSARC-ext@sun.com, Nagakiran.Rajashekar@sun.com Message-id: <488E5372.2070401@Egenera.COM> MIME-version: 1.0 Content-type: text/plain; charset=ISO-8859-1; format=flowed Content-transfer-encoding: 7BIT X-PMX-Version: 5.4.1.325704 X-Brightmail-Tracker: AAAAAA== X-Antispam: No, score=0.0/5.0, scanned in 0.050sec at (localhost [127.0.0.1]) by smf-spamd v1.3.1 - http://smfs.sf.net/ References: <488E141C.9060003@sun.com> <488E201D.1070004@sun.com> <488E29EB.5080803@Sun.COM> <488E2CB7.4020700@sun.com> <20080728221732.GA25547@Sun.COM> <488E4A8E.8090406@sun.com> <20080728225006.GE25547@Sun.COM> User-Agent: Thunderbird 2.0.0.16 (Windows/20080708) X-OriginalArrivalTime: 28 Jul 2008 23:17:54.0610 (UTC) FILETIME=[29F65120:01C8F108] Status: RO Content-Length: 1145 Nicolas Williams wrote: > I don't. cachefs like behaviour could be useful for CIFS as well (and > some day WebDAV too, why not, and maybe the AFS community would use the > infrastructure if available). > > The problem with cachefs is that it needs to be a service provided to > filesystems that filesystems must use explicitly. > > As far as what a replacement for CacheFS might be able to do, I'd like to see even more of a 'Work Offline' feature than it had in th past. Nico mentions using it for CIFS, and Allowing the user to select files to be available all the time (on or offline) is one feature CIFS has had for a while now, and one I find myslef wishing for often when running Solaris on a laptop. I've used CacheFS quite a bit in the past (mostly for NFS distribution of application binaries) and I had planned to use it again in the work I'm doing now, well on Solaris anyway, my Linux clients won't have it. If it, or something like it were to ever offer true 'work-offline' (with or without synchronize on reconnect - useful for r/w, but not needed for r/o) I'd end up using it all the time. -Kyle > Nico > From Andrew.Gabriel@sun.com Mon Jul 28 16:57:01 2008 Received: from sunmail5.uk.sun.com (sunmail5.UK.Sun.COM [129.156.85.165]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id m6SNv17i008602 for ; Mon, 28 Jul 2008 16:57:01 -0700 (PDT) Received: from nwk-avmta-1.SFBay.Sun.COM (nwk-avmta-1.SFBay.Sun.COM [129.146.11.74]) by sunmail5.uk.sun.com (8.13.8+Sun/8.13.8/ENSMAIL,v2.2) with ESMTP id m6SNupx7004683 for <@sunmail2sca.sfbay.sun.com:PSARC-ext@sun.com>; Tue, 29 Jul 2008 00:57:00 +0100 (BST) Received: from pmxchannel-daemon.nwk-avmta-1.sfbay.Sun.COM by nwk-avmta-1.sfbay.Sun.COM (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0K4Q00D03QIXRP00@nwk-avmta-1.sfbay.Sun.COM> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Mon, 28 Jul 2008 16:56:57 -0700 (PDT) Received: from gmp-eb-inf-1.sun.com ([192.18.6.21]) by nwk-avmta-1.sfbay.Sun.COM (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0K4Q00AFNQIWLP30@nwk-avmta-1.sfbay.Sun.COM> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Mon, 28 Jul 2008 16:56:57 -0700 (PDT) Received: from fe-emea-09.sun.com (gmp-eb-lb-2-fe1.eu.sun.com [192.18.6.10]) by gmp-eb-inf-1.sun.com (8.13.7+Sun/8.12.9) with ESMTP id m6SNuuAs000214 for ; Mon, 28 Jul 2008 23:56:56 +0000 (GMT) Received: from conversion-daemon.fe-emea-09.sun.com by fe-emea-09.sun.com (Sun Java System Messaging Server 6.2-8.04 (built Feb 28 2007)) id <0K4Q00A01QEHAS00@fe-emea-09.sun.com> (original mail from Andrew.Gabriel@Sun.COM) for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Tue, 29 Jul 2008 00:56:56 +0100 (BST) Received: from [192.9.200.17] ([81.187.162.106]) by fe-emea-09.sun.com (Sun Java System Messaging Server 6.2-8.04 (built Feb 28 2007)) with ESMTPSA id <0K4Q00C03QIW9I90@fe-emea-09.sun.com> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Tue, 29 Jul 2008 00:56:56 +0100 (BST) Date: Tue, 29 Jul 2008 00:58:32 +0100 From: Andrew Gabriel Subject: Re: EOF of Cache FileSystem (cachefs) [PSARC/2008/478 FastTrack timeout 08/04/2008] In-reply-to: <488E4A8E.8090406@sun.com> Sender: Andrew.Gabriel@sun.com Cc: PSARC-ext@sun.com Message-id: <488E5D28.60605@sun.com> MIME-version: 1.0 Content-type: text/plain; format=flowed; charset=ISO-8859-1 Content-transfer-encoding: 7BIT X-PMX-Version: 5.4.1.325704 References: <488E141C.9060003@sun.com> <488E201D.1070004@sun.com> <488E29EB.5080803@Sun.COM> <488E2CB7.4020700@sun.com> <20080728221732.GA25547@Sun.COM> <488E4A8E.8090406@sun.com> User-Agent: Thunderbird 2.0.0.14 (X11/20080519) Status: RO Content-Length: 586 Garrett D'Amore wrote: > Nicolas Williams wrote: >> It's a small gap. >> >> I think where it really matters one might use ZFS with iSCSI vdevs and a >> local L2ARC device. >> > > An interesting idea. I am not too familiar with iSCSI, but don't you > need an iSCSI target? I'm not sure, is iSCSI seeing deployment outside > of the data center? (NFS is designed to support concurrent network use > and reasonably handles multiple "intiators". How does iSCSI deal with > such a situation?) Gosh, we're nearly back to the SunOS 2 nd (network disk) protocol... ;-) -- Andrew From Darren.Reed@sun.com Mon Jul 28 19:16:33 2008 Received: from sunmail5.uk.sun.com (sunmail5.UK.Sun.COM [129.156.85.165]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id m6T2GWko013182 for ; Mon, 28 Jul 2008 19:16:33 -0700 (PDT) Received: from nwk-avmta-1.SFBay.Sun.COM (nwk-avmta-1.SFBay.Sun.COM [129.146.11.74]) by sunmail5.uk.sun.com (8.13.8+Sun/8.13.8/ENSMAIL,v2.2) with ESMTP id m6T2GL8l024264 for <@sunmail2sca.sfbay.sun.com:PSARC-ext@sun.com>; Tue, 29 Jul 2008 03:16:32 +0100 (BST) Received: from pmxchannel-daemon.nwk-avmta-1.sfbay.Sun.COM by nwk-avmta-1.sfbay.Sun.COM (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0K4Q00601WZIYZ00@nwk-avmta-1.sfbay.Sun.COM> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Mon, 28 Jul 2008 19:16:31 -0700 (PDT) Received: from gmp-eb-inf-1.sun.com ([192.18.6.21]) by nwk-avmta-1.sfbay.Sun.COM (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0K4Q0037OWZHZF70@nwk-avmta-1.sfbay.Sun.COM> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Mon, 28 Jul 2008 19:16:30 -0700 (PDT) Received: from fe-emea-10.sun.com (gmp-eb-lb-2-fe1.eu.sun.com [192.18.6.10]) by gmp-eb-inf-1.sun.com (8.13.7+Sun/8.12.9) with ESMTP id m6T2GTDq004295 for ; Tue, 29 Jul 2008 02:16:29 +0000 (GMT) Received: from conversion-daemon.fe-emea-10.sun.com by fe-emea-10.sun.com (Sun Java System Messaging Server 6.2-8.04 (built Feb 28 2007)) id <0K4Q00201WSILO00@fe-emea-10.sun.com> (original mail from Darren.Reed@Sun.COM) for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Tue, 29 Jul 2008 03:16:29 +0100 (BST) Received: from [129.146.106.55] by fe-emea-10.sun.com (Sun Java System Messaging Server 6.2-8.04 (built Feb 28 2007)) with ESMTPSA id <0K4Q005OZWZBYQ70@fe-emea-10.sun.com> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Tue, 29 Jul 2008 03:16:25 +0100 (BST) Date: Mon, 28 Jul 2008 19:16:23 -0700 From: Darren Reed Subject: Re: EOF of Cache FileSystem (cachefs) [PSARC/2008/478 FastTrack timeout 08/04/2008] In-reply-to: <20080728225006.GE25547@Sun.COM> Sender: Darren.Reed@sun.com To: Nicolas Williams Cc: "Garrett D'Amore" , Darren J Moffat , Daniel Hain , psarc-ext@sun.com, Nagakiran.Rajashekar@sun.com Message-id: <488E7D77.4040508@Sun.COM> MIME-version: 1.0 Content-type: text/plain; format=flowed; charset=us-ascii Content-transfer-encoding: 7BIT X-Accept-Language: en-au, en X-PMX-Version: 5.4.1.325704 References: <488E141C.9060003@sun.com> <488E201D.1070004@sun.com> <488E29EB.5080803@Sun.COM> <488E2CB7.4020700@sun.com> <20080728221732.GA25547@Sun.COM> <488E4A8E.8090406@sun.com> <20080728225006.GE25547@Sun.COM> User-Agent: Mozilla/5.0 (X11; U; SunOS i86pc; en-US; rv:1.7) Gecko/20060120 Status: RO Content-Length: 1097 Nicolas Williams wrote: > ... > >>It would be nice to see a commitment to closing any remaining gap as >>much as possible, perhaps by further development of NFSv4 -- as others >>have suggested. >> >>As a final note, I do recall that cachefs was supposed to be generic for >>things like cdroms, etc. I do agree with the proposal that cachefs like >>behavior for anything *other than NFS* is probably not terribly interesting. >> >> > >I don't. cachefs like behaviour could be useful for CIFS as well (and >some day WebDAV too, why not, and maybe the AFS community would use the >infrastructure if available). > >The problem with cachefs is that it needs to be a service provided to >filesystems that filesystems must use explicitly. > > To me it sounds like you are saying that cachefs is a nice answer but that its current architecture isn't suitable for a role more wisespread than just NFS. Given this we may as well EOL cachefs and replace it at some point in the future with a feature that does a better job of caching any network based filesystem, not just NFS, right? Darren From nagki@sun.com Mon Jul 28 20:24:26 2008 Received: from sunmail5.uk.sun.com (sunmail5.UK.Sun.COM [129.156.85.165]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id m6T3OPHe014209 for ; Mon, 28 Jul 2008 20:24:26 -0700 (PDT) Received: from nwk-avmta-1.SFBay.Sun.COM (nwk-avmta-1.SFBay.Sun.COM [129.146.11.74]) by sunmail5.uk.sun.com (8.13.8+Sun/8.13.8/ENSMAIL,v2.2) with ESMTP id m6T3OGs7017173 for <@sunmail2sca.sfbay.sun.com:psarc-ext@sun.com>; Tue, 29 Jul 2008 04:24:25 +0100 (BST) Received: from pmxchannel-daemon.nwk-avmta-1.sfbay.Sun.COM by nwk-avmta-1.sfbay.Sun.COM (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0K4R00E2B04LRH00@nwk-avmta-1.sfbay.Sun.COM> for psarc-ext@sun.com (ORCPT psarc-ext@Sun.COM); Mon, 28 Jul 2008 20:24:21 -0700 (PDT) Received: from sineb-mail-2.sun.com ([192.18.19.7]) by nwk-avmta-1.sfbay.Sun.COM (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0K4R00AGQ04JB110@nwk-avmta-1.sfbay.Sun.COM> for psarc-ext@sun.com (ORCPT psarc-ext@Sun.COM); Mon, 28 Jul 2008 20:24:20 -0700 (PDT) Received: from fe-apac-05.sun.com (fe-apac-05.sun.com [192.18.19.176] (may be forged)) by sineb-mail-2.sun.com (8.13.6+Sun/8.12.9) with ESMTP id m6T3PVc8020691 for ; Tue, 29 Jul 2008 03:25:31 +0000 (GMT) Received: from conversion-daemon.mail-apac.sun.com by mail-apac.sun.com (Sun Java System Messaging Server 6.2-6.01 (built Apr 3 2006)) id <0K4Q00M01ZY7KM00@mail-apac.sun.com> (original mail from nagki@sun.com) for psarc-ext@Sun.COM (ORCPT psarc-ext@Sun.COM); Tue, 29 Jul 2008 11:23:45 +0800 (SGT) Received: from [129.158.226.22] by mail-apac.sun.com (Sun Java System Messaging Server 6.2-6.01 (built Apr 3 2006)) with ESMTPSA id <0K4R004BD03KPGA6@mail-apac.sun.com> for psarc-ext@Sun.COM (ORCPT psarc-ext@Sun.COM); Tue, 29 Jul 2008 11:23:45 +0800 (SGT) Date: Tue, 29 Jul 2008 08:58:50 +0530 From: "Nagakiran K.R" Subject: Re: EOF of Cache FileSystem (cachefs) [PSARC/2008/478 FastTrack timeout 08/04/2008] In-reply-to: <488E7D77.4040508@Sun.COM> Sender: Nagakiran.Rajashekar@sun.com To: Darren Reed Cc: Nicolas Williams , "Garrett D'Amore" , Darren J Moffat , Daniel Hain , psarc-ext@sun.com, Nagakiran.Rajashekar@sun.com Message-id: <488E8E72.1000704@sun.com> MIME-version: 1.0 Content-type: text/plain; format=flowed; charset=ISO-8859-1 Content-transfer-encoding: 7BIT X-PMX-Version: 5.4.1.325704 References: <488E141C.9060003@sun.com> <488E201D.1070004@sun.com> <488E29EB.5080803@Sun.COM> <488E2CB7.4020700@sun.com> <20080728221732.GA25547@Sun.COM> <488E4A8E.8090406@sun.com> <20080728225006.GE25547@Sun.COM> <488E7D77.4040508@Sun.COM> User-Agent: Thunderbird 2.0.0.6 (X11/20071119) Status: RO Content-Length: 2171 Darren Reed wrote: > Nicolas Williams wrote: > >> ... >> >>> It would be nice to see a commitment to closing any remaining gap as >>> much as possible, perhaps by further development of NFSv4 -- as >>> others have suggested. >>> >>> As a final note, I do recall that cachefs was supposed to be generic >>> for things like cdroms, etc. I do agree with the proposal that >>> cachefs like behavior for anything *other than NFS* is probably not >>> terribly interesting. >>> >> >> I don't. cachefs like behaviour could be useful for CIFS as well (and >> some day WebDAV too, why not, and maybe the AFS community would use the >> infrastructure if available). >> >> The problem with cachefs is that it needs to be a service provided to >> filesystems that filesystems must use explicitly. >> >> > > To me it sounds like you are saying that cachefs is a nice answer > but that its current architecture isn't suitable for a role more > wisespread than just NFS. Given this we may as well EOL cachefs > and replace it at some point in the future with a feature that does > a better job of caching any network based filesystem, not just NFS, > right? The problem here is that cachefs is not generic caching solution as of now, It is agreed that we need a persistent caching need for the network based filesystem, but retaining cachefs to provide that functionality is a support nightmare - Current code is not generic and uses suboptimal use of generic kernel functions. - knows a lot about UFS (local cache) and NFS v2 and v3 - Can't work with NFS v4 (becauase of (2)) and changes required to make it seemlessly work with NFS v4 is almost like a new project. While having a requirement to provide persistent cache for certain workload is a good idea, its the consistency that suffers today with cachefs when pushed to an environment where multiple clients modify the data on the server. I think the current code is unmaintainable, I suggest any new request for providing persistent cache for Network filesystems should be handled via a new project. cachefs is not suitable for these kind of modifications at the moment. Regards Kiran From Matthew.Jacob@Sun.COM Mon Jul 28 23:40:20 2008 Received: from sunmail3mpk.sfbay.sun.com (sunmail3mpk.SFBay.Sun.COM [129.146.11.52]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id m6T6eJMo019190 for ; Mon, 28 Jul 2008 23:40:19 -0700 (PDT) Received: from brm-avmta-1.central.sun.com (brm-avmta-1.Central.Sun.COM [129.147.4.11]) by sunmail3mpk.sfbay.sun.com (8.13.7+Sun/8.13.7/ENSMAIL,v2.2) with ESMTP id m6T6eJaU020296 for <@sunmail2sca.sfbay.sun.com:PSARC-ext@sun.com>; Mon, 28 Jul 2008 23:40:19 -0700 (PDT) Received: from pmxchannel-daemon.brm-avmta-1.central.sun.com by brm-avmta-1.central.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0K4R00G03975NR00@brm-avmta-1.central.sun.com> for PSARC-ext@sun.com (ORCPT PSARC-ext@Sun.COM); Tue, 29 Jul 2008 00:40:17 -0600 (MDT) Received: from sca-es-mail-2.sun.com ([192.18.43.133]) by brm-avmta-1.central.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0K4R0094I9747V60@brm-avmta-1.central.sun.com> for PSARC-ext@sun.com (ORCPT PSARC-ext@Sun.COM); Tue, 29 Jul 2008 00:40:16 -0600 (MDT) Received: from fe-sfbay-10.sun.com ([192.18.43.129]) by sca-es-mail-2.sun.com (8.13.7+Sun/8.12.9) with ESMTP id m6T6eGtU013842 for ; Mon, 28 Jul 2008 23:40:16 -0700 (PDT) Received: from conversion-daemon.fe-sfbay-10.sun.com by fe-sfbay-10.sun.com (Sun Java System Messaging Server 6.2-8.04 (built Feb 28 2007)) id <0K4R00J01950OU00@fe-sfbay-10.sun.com> (original mail from Matthew.Jacob@Sun.COM) for PSARC-ext@Sun.COM (ORCPT PSARC-ext@Sun.COM); Mon, 28 Jul 2008 23:40:16 -0700 (PDT) Received: from [192.168.1.101] ([216.101.109.56]) by fe-sfbay-10.sun.com (Sun Java System Messaging Server 6.2-8.04 (built Feb 28 2007)) with ESMTPSA id <0K4R00KFV974C6D0@fe-sfbay-10.sun.com> for PSARC-ext@Sun.COM (ORCPT PSARC-ext@Sun.COM); Mon, 28 Jul 2008 23:40:16 -0700 (PDT) Date: Mon, 28 Jul 2008 23:38:05 -0700 From: Matthew Jacob Subject: Re: EOF of Cache FileSystem (cachefs) [PSARC/2008/478 FastTrack timeout 08/04/2008] In-reply-to: <488E5D28.60605@sun.com> Sender: Matthew.Jacob@Sun.COM To: Andrew Gabriel Cc: PSARC-ext@Sun.COM Message-id: <488EBACD.2020907@sun.com> MIME-version: 1.0 Content-type: text/plain; format=flowed; charset=ISO-8859-1 Content-transfer-encoding: 7BIT X-PMX-Version: 5.4.1.325704 References: <488E141C.9060003@sun.com> <488E201D.1070004@sun.com> <488E29EB.5080803@Sun.COM> <488E2CB7.4020700@sun.com> <20080728221732.GA25547@Sun.COM> <488E4A8E.8090406@sun.com> <488E5D28.60605@sun.com> User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.8.1.13) Gecko/20080313 SeaMonkey/1.1.9 Status: RO Content-Length: 752 Andrew Gabriel wrote: > Garrett D'Amore wrote: >> Nicolas Williams wrote: >>> It's a small gap. >>> >>> I think where it really matters one might use ZFS with iSCSI vdevs >>> and a >>> local L2ARC device. >>> >> >> An interesting idea. I am not too familiar with iSCSI, but don't >> you need an iSCSI target? I'm not sure, is iSCSI seeing deployment >> outside of the data center? (NFS is designed to support concurrent >> network use and reasonably handles multiple "intiators". How does >> iSCSI deal with such a situation?) > > Gosh, we're nearly back to the SunOS 2 nd (network disk) protocol... ;-) > Hmm. That's the best suggestion I've seen since I came back to Sun. Let's see now, where's my "Fixed in [SunOS] 4.0" t-shirt....? From Joerg.Schilling@fokus.fraunhofer.de Tue Jul 29 01:32:31 2008 Received: from sunmail3mpk.sfbay.sun.com (sunmail3mpk.SFBay.Sun.COM [129.146.11.52]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id m6T8WVuL022723 for ; Tue, 29 Jul 2008 01:32:31 -0700 (PDT) Received: from nwk-avmta-2.sfbay.sun.com (nwk-avmta-2.SFBay.Sun.COM [129.145.155.6]) by sunmail3mpk.sfbay.sun.com (8.13.7+Sun/8.13.7/ENSMAIL,v2.2) with ESMTP id m6T8WQno020844; Tue, 29 Jul 2008 01:32:27 -0700 (PDT) Received: from pmxchannel-daemon.nwk-avmta-2.sfbay.sun.com by nwk-avmta-2.sfbay.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0K4R00F05EE2Q800@nwk-avmta-2.sfbay.sun.com>; Tue, 29 Jul 2008 01:32:26 -0700 (PDT) Received: from brmea-mail-4.sun.com ([192.18.98.36]) by nwk-avmta-2.sfbay.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0K4R008INEE1LG90@nwk-avmta-2.sfbay.sun.com>; Tue, 29 Jul 2008 01:32:26 -0700 (PDT) Received: from relay12i.sun.com (ip122.net129179-4.block1.us.syntegra.com [129.179.4.122]) by brmea-mail-4.sun.com (8.13.6+Sun/8.12.9) with ESMTP id m6T8SXKx000129; Tue, 29 Jul 2008 08:32:25 +0000 (GMT) Received: from mmp14es.mmp.us.syntegra.com ([160.41.208.14] [160.41.208.14]) by relay12i.sun.com with ESMTP id BT-MMP-418037; Tue, 29 Jul 2008 08:32:25 +0000 (Z) Received: from relay16i.sun.com (relay16i.sun.com [129.179.4.126]) by mmp14es.mmp.us.syntegra.com with ESMTP id BT-MMP-345420; Tue, 29 Jul 2008 08:32:22 +0000 (Z) Received: from mailgw1.fraunhofer.de ([153.96.1.17] [153.96.1.17]) by relay1i.sun.com with ESMTP id BT-MMP-2542850; Tue, 29 Jul 2008 08:32:21 +0000 (Z) Received: from mailgw1.fraunhofer.de (localhost [127.0.0.1]) by mailgw1.fraunhofer.de[host mailgw22] (8.14.2+/8.14.2) with ESMTP id m6T8W8BG024519; Tue, 29 Jul 2008 10:32:08 +0200 (CEST) Received: from pluto.fokus.fraunhofer.de (pluto.fokus.fraunhofer.de [195.37.77.164]) by mailgw1.fraunhofer.de (8.14.2+/8.14.2) with ESMTP id m6T8W7kL024515 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Tue, 29 Jul 2008 10:32:07 +0200 (CEST) Received: from EXCHSRV.fokus.fraunhofer.de (bohr [10.147.9.231]) by pluto.fokus.fraunhofer.de (8.13.7/8.13.7) with SMTP id m6T8W6Ko026465; Tue, 29 Jul 2008 10:32:07 +0200 (MEST) Received: from rigel ([10.147.65.195]) by EXCHSRV.fokus.fraunhofer.de with Microsoft SMTPSVC(6.0.3790.3959); Tue, 29 Jul 2008 10:32:06 +0200 Date: Tue, 29 Jul 2008 10:32:03 +0200 From: Joerg.Schilling@fokus.fraunhofer.de (Joerg Schilling) Subject: Re: EOF of Cache FileSystem (cachefs) [PSARC/2008/478 FastTrack timeout 08/04/2008] In-reply-to: <488E5372.2070401@Egenera.COM> To: PSARC-ext@sun.com, Nagakiran.Rajashekar@sun.com, KMcDonald@egenera.com, gdamore@sun.com, Darren.Moffat@sun.com, Daniel.Hain@sun.com Message-id: <488ed583.NWaDBV+/boGUWNyI%Joerg.Schilling@fokus.fraunhofer.de> MIME-version: 1.0 Content-type: text/plain; charset=ISO-8859-1 Content-transfer-encoding: 8BIT X-PMX-Version: 5.4.1.325704 X-Brightmail-Tracker: AAAAAA== X-Fraunhofer-Email-Policy: accepted X-Antispam: No, score=0.0/5.0, scanned in 2.323sec at (localhost [127.0.0.1]) by smf-spamd v1.3.1 - http://smfs.sf.net/ References: <488E141C.9060003@sun.com> <488E201D.1070004@sun.com> <488E29EB.5080803@Sun.COM> <488E2CB7.4020700@sun.com> <20080728221732.GA25547@Sun.COM> <488E4A8E.8090406@sun.com> <20080728225006.GE25547@Sun.COM> <488E5372.2070401@Egenera.COM> User-Agent: nail 11.22 3/20/05 X-OriginalArrivalTime: 29 Jul 2008 08:32:06.0955 (UTC) FILETIME=[95E77FB0:01C8F155] Status: RO Content-Length: 886 Kyle McDonald wrote: > As far as what a replacement for CacheFS might be able to do, I'd like > to see even more of a 'Work Offline' feature than it had in th past. > Nico mentions using it for CIFS, and Allowing the user to select files > to be available all the time (on or offline) is one feature CIFS has had > for a while now, and one I find myslef wishing for often when running > Solaris on a laptop. What we also need iss something like an overlay filesystem. This helps to make life (CD based) boot environments useful for more than simple tests. Jörg -- EMail:joerg@schily.isdn.cs.tu-berlin.de (home) Jörg Schilling D-13353 Berlin js@cs.tu-berlin.de (uni) schilling@fokus.fraunhofer.de (work) Blog: http://schily.blogspot.com/ URL: http://cdrecord.berlios.de/old/private/ ftp://ftp.berlios.de/pub/schily From Joerg.Schilling@fokus.fraunhofer.de Tue Jul 29 01:34:01 2008 Received: from sunmail4.singapore.sun.com (sunmail4.Singapore.Sun.COM [129.158.71.19]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id m6T8Y0Cg022738 for ; Tue, 29 Jul 2008 01:34:00 -0700 (PDT) Received: from nwk-avmta-1.SFBay.Sun.COM (nwk-avmta-1.SFBay.Sun.COM [129.146.11.74]) by sunmail4.singapore.sun.com (8.13.4+Sun/8.13.3/ENSMAIL,v2.2) with ESMTP id m6T8Xver004582; Tue, 29 Jul 2008 16:33:57 +0800 (SGT) Received: from pmxchannel-daemon.nwk-avmta-1.sfbay.Sun.COM by nwk-avmta-1.sfbay.Sun.COM (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0K4R00601EGKX600@nwk-avmta-1.sfbay.Sun.COM>; Tue, 29 Jul 2008 01:33:56 -0700 (PDT) Received: from sca-ea-mail-4.sun.com ([192.18.43.22]) by nwk-avmta-1.sfbay.Sun.COM (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0K4R003OUEGHPH20@nwk-avmta-1.sfbay.Sun.COM>; Tue, 29 Jul 2008 01:33:53 -0700 (PDT) Received: from relay16i.sun.com (ip126.net129179-4.block1.us.syntegra.com [129.179.4.126]) by sca-ea-mail-4.sun.com (8.13.6+Sun/8.12.9) with ESMTP id m6T8XCOO010015; Tue, 29 Jul 2008 08:33:53 +0000 (GMT) Received: from mmp13es.mmp.us.syntegra.com ([160.41.208.13] [160.41.208.13]) by relay16i.sun.com with ESMTP id BT-MMP-417779; Tue, 29 Jul 2008 08:33:52 +0000 (Z) Received: from relay14i.sun.com (relay14i.sun.com [129.179.4.124]) by mmp13es.mmp.us.syntegra.com with ESMTP id BT-MMP-349539; Tue, 29 Jul 2008 08:33:52 +0000 (Z) Received: from mailgw1.fraunhofer.de ([153.96.1.17] [153.96.1.17]) by relay1ib.sun.com with ESMTP id BT-MMP-2703838; Tue, 29 Jul 2008 08:33:52 +0000 (Z) Received: from mailgw1.fraunhofer.de (localhost [127.0.0.1]) by mailgw1.fraunhofer.de[host mailgw27] (8.14.2+/8.14.2) with ESMTP id m6T8Xpjo014553; Tue, 29 Jul 2008 10:33:51 +0200 (CEST) Received: from pluto.fokus.fraunhofer.de (pluto.fokus.fraunhofer.de [195.37.77.164]) by mailgw1.fraunhofer.de (8.14.2+/8.14.2) with ESMTP id m6T8XoFp014550 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Tue, 29 Jul 2008 10:33:51 +0200 (CEST) Received: from EXCHSRV.fokus.fraunhofer.de (bohr [10.147.9.231]) by pluto.fokus.fraunhofer.de (8.13.7/8.13.7) with SMTP id m6T8XoUN026535; Tue, 29 Jul 2008 10:33:50 +0200 (MEST) Received: from rigel ([10.147.65.195]) by EXCHSRV.fokus.fraunhofer.de with Microsoft SMTPSVC(6.0.3790.3959); Tue, 29 Jul 2008 10:33:50 +0200 Date: Tue, 29 Jul 2008 10:33:50 +0200 From: Joerg.Schilling@fokus.fraunhofer.de (Joerg Schilling) Subject: Re: EOF of Cache FileSystem (cachefs) [PSARC/2008/478 FastTrack timeout 08/04/2008] In-reply-to: <488E5D28.60605@sun.com> To: Andrew.Gabriel@sun.com Cc: PSARC-ext@sun.com Message-id: <488ed5ee.ENutaIm+RDhG24n5%Joerg.Schilling@fokus.fraunhofer.de> MIME-version: 1.0 Content-type: text/plain; charset=ISO-8859-1 Content-transfer-encoding: 8BIT X-PMX-Version: 5.4.1.325704 X-Brightmail-Tracker: AAAAAA== X-Fraunhofer-Email-Policy: accepted X-Antispam: No, score=0.0/5.0, scanned in 0.068sec at (localhost [127.0.0.1]) by smf-spamd v1.3.1 - http://smfs.sf.net/ References: <488E141C.9060003@sun.com> <488E201D.1070004@sun.com> <488E29EB.5080803@Sun.COM> <488E2CB7.4020700@sun.com> <20080728221732.GA25547@Sun.COM> <488E4A8E.8090406@sun.com> <488E5D28.60605@sun.com> User-Agent: nail 11.22 3/20/05 X-OriginalArrivalTime: 29 Jul 2008 08:33:50.0677 (UTC) FILETIME=[D3BA3850:01C8F155] Status: RO Content-Length: 862 Andrew Gabriel wrote: > > An interesting idea. I am not too familiar with iSCSI, but don't you > > need an iSCSI target? I'm not sure, is iSCSI seeing deployment outside > > of the data center? (NFS is designed to support concurrent network use > > and reasonably handles multiple "intiators". How does iSCSI deal with > > such a situation?) > > Gosh, we're nearly back to the SunOS 2 nd (network disk) protocol... ;-) In those days many clients did mount the ND partitions. Fun if you let more than one do it non-readonly ;-) Jörg -- EMail:joerg@schily.isdn.cs.tu-berlin.de (home) Jörg Schilling D-13353 Berlin js@cs.tu-berlin.de (uni) schilling@fokus.fraunhofer.de (work) Blog: http://schily.blogspot.com/ URL: http://cdrecord.berlios.de/old/private/ ftp://ftp.berlios.de/pub/schily From Joerg.Schilling@fokus.fraunhofer.de Tue Jul 29 01:57:38 2008 Received: from sunmail4.singapore.sun.com (sunmail4.Singapore.Sun.COM [129.158.71.19]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id m6T8vbep023314 for ; Tue, 29 Jul 2008 01:57:37 -0700 (PDT) Received: from nwk-avmta-1.SFBay.Sun.COM (nwk-avmta-1.SFBay.Sun.COM [129.146.11.74]) by sunmail4.singapore.sun.com (8.13.4+Sun/8.13.3/ENSMAIL,v2.2) with ESMTP id m6T8vVwf013146; Tue, 29 Jul 2008 16:57:33 +0800 (SGT) Received: from pmxchannel-daemon.nwk-avmta-1.sfbay.Sun.COM by nwk-avmta-1.sfbay.Sun.COM (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0K4R00903FJUK900@nwk-avmta-1.sfbay.Sun.COM>; Tue, 29 Jul 2008 01:57:30 -0700 (PDT) Received: from brmea-mail-3.sun.com ([192.18.98.34]) by nwk-avmta-1.sfbay.Sun.COM (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0K4R003NPFJUPC40@nwk-avmta-1.sfbay.Sun.COM>; Tue, 29 Jul 2008 01:57:30 -0700 (PDT) Received: from relay22.sun.com (relay22.sun.com [192.12.251.34] (may be forged)) by brmea-mail-3.sun.com (8.13.6+Sun/8.12.9) with ESMTP id m6T8uXhh015327; Tue, 29 Jul 2008 08:57:30 +0000 (GMT) Received: from mms22es.mms.us.syntegra.com ([150.143.232.30] [150.143.232.30]) by relay22i.sun.com with ESMTP id BT-MMP-606879; Tue, 29 Jul 2008 08:57:29 +0000 (Z) Received: from relay22.sun.com (relay22.sun.com [192.12.251.34]) by mms22es.mms.us.syntegra.com with ESMTP id BT-MMP-19302711; Tue, 29 Jul 2008 08:57:29 +0000 (Z) Received: from mailgw1.fraunhofer.de ([153.96.1.17] [153.96.1.17]) by relay22i.sun.com with ESMTP id BT-MMP-10223753; Tue, 29 Jul 2008 08:57:29 +0000 (Z) Received: from mailgw1.fraunhofer.de (localhost [127.0.0.1]) by mailgw1.fraunhofer.de[host mailgw25] (8.14.2+/8.14.2) with ESMTP id m6T8vEFw008698; Tue, 29 Jul 2008 10:57:14 +0200 (CEST) Received: from pluto.fokus.fraunhofer.de (pluto.fokus.fraunhofer.de [195.37.77.164]) by mailgw1.fraunhofer.de (8.14.2+/8.14.2) with ESMTP id m6T8vDKL008686 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Tue, 29 Jul 2008 10:57:14 +0200 (CEST) Received: from EXCHSRV.fokus.fraunhofer.de (bohr [10.147.9.231]) by pluto.fokus.fraunhofer.de (8.13.7/8.13.7) with SMTP id m6T8vD10027618; Tue, 29 Jul 2008 10:57:13 +0200 (MEST) Received: from rigel ([10.147.65.195]) by EXCHSRV.fokus.fraunhofer.de with Microsoft SMTPSVC(6.0.3790.3959); Tue, 29 Jul 2008 10:57:12 +0200 Date: Tue, 29 Jul 2008 10:57:12 +0200 From: Joerg.Schilling@fokus.fraunhofer.de (Joerg Schilling) Subject: Re: EOF of Cache FileSystem (cachefs) [PSARC/2008/478 FastTrack timeout 08/04/2008] In-reply-to: <488EBACD.2020907@sun.com> To: Matthew.Jacob@sun.com, Andrew.Gabriel@sun.com Cc: PSARC-ext@sun.com Message-id: <488edb68.mdXYWtzDEZ0Wlvca%Joerg.Schilling@fokus.fraunhofer.de> MIME-version: 1.0 Content-type: text/plain; charset=ISO-8859-1 Content-transfer-encoding: 8BIT X-PMX-Version: 5.4.1.325704 X-Brightmail-Tracker: AAAAAA== X-Fraunhofer-Email-Policy: accepted X-Antispam: No, score=0.0/5.0, scanned in 0.057sec at (localhost [127.0.0.1]) by smf-spamd v1.3.1 - http://smfs.sf.net/ References: <488E141C.9060003@sun.com> <488E201D.1070004@sun.com> <488E29EB.5080803@Sun.COM> <488E2CB7.4020700@sun.com> <20080728221732.GA25547@Sun.COM> <488E4A8E.8090406@sun.com> <488E5D28.60605@sun.com> <488EBACD.2020907@sun.com> User-Agent: nail 11.22 3/20/05 X-OriginalArrivalTime: 29 Jul 2008 08:57:12.0941 (UTC) FILETIME=[178AB9D0:01C8F159] Status: RO Content-Length: 656 Matthew Jacob wrote: > > Gosh, we're nearly back to the SunOS 2 nd (network disk) protocol... ;-) > > > Hmm. That's the best suggestion I've seen since I came back to Sun. > Let's see now, where's my "Fixed in [SunOS] 4.0" t-shirt....? This distinguishes us old guys from those who still like to make the related experiences ;-) Jörg -- EMail:joerg@schily.isdn.cs.tu-berlin.de (home) Jörg Schilling D-13353 Berlin js@cs.tu-berlin.de (uni) schilling@fokus.fraunhofer.de (work) Blog: http://schily.blogspot.com/ URL: http://cdrecord.berlios.de/old/private/ ftp://ftp.berlios.de/pub/schily From nagki@sun.com Tue Jul 29 02:06:49 2008 Received: from sunmail3mpk.sfbay.sun.com (sunmail3mpk.SFBay.Sun.COM [129.146.11.52]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id m6T96n9X023533 for ; Tue, 29 Jul 2008 02:06:49 -0700 (PDT) Received: from brm-avmta-1.central.sun.com (brm-avmta-1.Central.Sun.COM [129.147.4.11]) by sunmail3mpk.sfbay.sun.com (8.13.7+Sun/8.13.7/ENSMAIL,v2.2) with ESMTP id m6T96loJ000242; Tue, 29 Jul 2008 02:06:49 -0700 (PDT) Received: from pmxchannel-daemon.brm-avmta-1.central.sun.com by brm-avmta-1.central.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0K4R00405FZCIT00@brm-avmta-1.central.sun.com>; Tue, 29 Jul 2008 03:06:48 -0600 (MDT) Received: from sineb-mail-2.sun.com ([192.18.19.7]) by brm-avmta-1.central.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0K4R0041CFZ0H800@brm-avmta-1.central.sun.com>; Tue, 29 Jul 2008 03:06:48 -0600 (MDT) Received: from fe-apac-06.sun.com (fe-apac-06.sun.com [192.18.19.177] (may be forged)) by sineb-mail-2.sun.com (8.13.6+Sun/8.12.9) with ESMTP id m6T97mrC016799; Tue, 29 Jul 2008 09:07:48 +0000 (GMT) Received: from conversion-daemon.mail-apac.sun.com by mail-apac.sun.com (Sun Java System Messaging Server 6.2-6.01 (built Apr 3 2006)) id <0K4R00401FQH3N00@mail-apac.sun.com> (original mail from nagki@sun.com) ; Tue, 29 Jul 2008 17:04:02 +0800 (SGT) Received: from [10.0.2.15] ([192.18.192.76]) by mail-apac.sun.com (Sun Java System Messaging Server 6.2-6.01 (built Apr 3 2006)) with ESMTPSA id <0K4R009W5FUO8G8K@mail-apac.sun.com>; Tue, 29 Jul 2008 17:04:02 +0800 (SGT) Date: Tue, 29 Jul 2008 01:30:59 +0530 From: "Nagakiran K.R" Subject: Re: EOF of Cache FileSystem (cachefs) [PSARC/2008/478 FastTrack timeout 08/04/2008] In-reply-to: <488ed583.NWaDBV+/boGUWNyI%Joerg.Schilling@fokus.fraunhofer.de> Sender: Nagakiran.Rajashekar@sun.com To: PSARC-ext@sun.com Cc: Joerg Schilling , Nagakiran.Rajashekar@sun.com, KMcDonald@egenera.com, gdamore@sun.com, Darren.Moffat@sun.com, Daniel.Hain@sun.com, cachefs-eof-discuss@sun.com Message-id: <488E257B.90900@sun.com> MIME-version: 1.0 Content-type: text/plain; format=flowed; charset=ISO-8859-1 Content-transfer-encoding: 8BIT X-PMX-Version: 5.4.1.325704 References: <488E141C.9060003@sun.com> <488E201D.1070004@sun.com> <488E29EB.5080803@Sun.COM> <488E2CB7.4020700@sun.com> <20080728221732.GA25547@Sun.COM> <488E4A8E.8090406@sun.com> <20080728225006.GE25547@Sun.COM> <488E5372.2070401@Egenera.COM> <488ed583.NWaDBV+/boGUWNyI%Joerg.Schilling@fokus.fraunhofer.de> User-Agent: Thunderbird 2.0.0.9 (X11/20080225) Status: RO Content-Length: 793 Joerg Schilling wrote: > Kyle McDonald wrote: > > >> As far as what a replacement for CacheFS might be able to do, I'd like >> to see even more of a 'Work Offline' feature than it had in th past. >> Nico mentions using it for CIFS, and Allowing the user to select files >> to be available all the time (on or offline) is one feature CIFS has had >> for a while now, and one I find myslef wishing for often when running >> Solaris on a laptop. >> > > What we also need iss something like an overlay filesystem. This helps to make > life (CD based) boot environments useful for more than simple tests. > > Jörg > > Adding cachefs EOF alias to this discussion, so that other people who worked on cachefs in the past are involved aswell. Regards Kiran From Darren.Moffat@sun.com Tue Jul 29 02:43:26 2008 Received: from sunmail2sca.sfbay.sun.com (sunmail2sca.SFBay.Sun.COM [129.145.155.234]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id m6T9hQMH025573 for ; Tue, 29 Jul 2008 02:43:26 -0700 (PDT) Received: from brm-avmta-1.central.sun.com (brm-avmta-1.Central.Sun.COM [129.147.4.11]) by sunmail2sca.sfbay.sun.com (8.13.7+Sun/8.13.7/ENSMAIL,v2.2) with ESMTP id m6T9hPxR016091 for <@sunmail2sca.sfbay.sun.com:PSARC-ext@sun.com>; Tue, 29 Jul 2008 02:43:26 -0700 (PDT) Received: from pmxchannel-daemon.brm-avmta-1.central.sun.com by brm-avmta-1.central.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0K4R00707HOC5V00@brm-avmta-1.central.sun.com> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Tue, 29 Jul 2008 03:43:24 -0600 (MDT) Received: from gmp-eb-inf-1.sun.com ([192.18.6.21]) by brm-avmta-1.central.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0K4R004U8HOCGT10@brm-avmta-1.central.sun.com> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Tue, 29 Jul 2008 03:43:24 -0600 (MDT) Received: from fe-emea-10.sun.com (gmp-eb-lb-2-fe3.eu.sun.com [192.18.6.12]) by gmp-eb-inf-1.sun.com (8.13.7+Sun/8.12.9) with ESMTP id m6T9hNdD007369 for ; Tue, 29 Jul 2008 09:43:23 +0000 (GMT) Received: from conversion-daemon.fe-emea-10.sun.com by fe-emea-10.sun.com (Sun Java System Messaging Server 6.2-8.04 (built Feb 28 2007)) id <0K4R00501H9DFV00@fe-emea-10.sun.com> (original mail from Darren.Moffat@Sun.COM) for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Tue, 29 Jul 2008 10:43:23 +0100 (BST) Received: from [129.156.173.21] by fe-emea-10.sun.com (Sun Java System Messaging Server 6.2-8.04 (built Feb 28 2007)) with ESMTPSA id <0K4R00BU9HO5Q2A0@fe-emea-10.sun.com> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Tue, 29 Jul 2008 10:43:19 +0100 (BST) Date: Tue, 29 Jul 2008 10:43:17 +0100 From: Darren J Moffat Subject: Re: EOF of Cache FileSystem (cachefs) [PSARC/2008/478 FastTrack timeout 08/04/2008] In-reply-to: <488E51CB.9060507@Egenera.COM> Sender: Darren.Moffat@sun.com To: Kyle McDonald Cc: "Garrett D'Amore" , Daniel Hain , PSARC-ext@sun.com, Nagakiran.Rajashekar@sun.com Message-id: <488EE635.3080204@Sun.COM> MIME-version: 1.0 Content-type: text/plain; format=flowed; charset=ISO-8859-1 Content-transfer-encoding: 7BIT X-PMX-Version: 5.4.1.325704 References: <488E141C.9060003@sun.com> <488E201D.1070004@sun.com> <488E29EB.5080803@Sun.COM> <488E2CB7.4020700@sun.com> <20080728221732.GA25547@Sun.COM> <488E4A8E.8090406@sun.com> <20080728225006.GE25547@Sun.COM> <488E51CB.9060507@Egenera.COM> User-Agent: Thunderbird 2.0.0.14 (X11/20080630) Status: RO Content-Length: 453 Kyle McDonald wrote: > But you suggested using it in ZFS with a local L2ARC. Unless I've missed > something, I don't think you can share devices (iSCSI or not) between > different ZFS's on different hosts. Can you? You are correct that is not possible. There is no such thing as a read only ZFS pool at this time. Also the L2ARC even though it is written to persistent media does not get reused after a reboot at this time. -- Darren J Moffat From Darren.Moffat@sun.com Tue Jul 29 02:45:12 2008 Received: from sunmail2sca.sfbay.sun.com (sunmail2sca.SFBay.Sun.COM [129.145.155.234]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id m6T9jCap025587 for ; Tue, 29 Jul 2008 02:45:12 -0700 (PDT) Received: from brm-avmta-1.central.sun.com (brm-avmta-1.Central.Sun.COM [129.147.4.11]) by sunmail2sca.sfbay.sun.com (8.13.7+Sun/8.13.7/ENSMAIL,v2.2) with ESMTP id m6T9j4Px016442 for <@sunmail2sca.sfbay.sun.com:PSARC-ext@sun.com>; Tue, 29 Jul 2008 02:45:12 -0700 (PDT) Received: from pmxchannel-daemon.brm-avmta-1.central.sun.com by brm-avmta-1.central.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0K4R0070JHRAAF00@brm-avmta-1.central.sun.com> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Tue, 29 Jul 2008 03:45:10 -0600 (MDT) Received: from gmp-eb-inf-1.sun.com ([192.18.6.21]) by brm-avmta-1.central.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0K4R004VIHR8GT10@brm-avmta-1.central.sun.com> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Tue, 29 Jul 2008 03:45:09 -0600 (MDT) Received: from fe-emea-09.sun.com (gmp-eb-lb-2-fe3.eu.sun.com [192.18.6.12]) by gmp-eb-inf-1.sun.com (8.13.7+Sun/8.12.9) with ESMTP id m6T9j8Uu007828 for ; Tue, 29 Jul 2008 09:45:08 +0000 (GMT) Received: from conversion-daemon.fe-emea-09.sun.com by fe-emea-09.sun.com (Sun Java System Messaging Server 6.2-8.04 (built Feb 28 2007)) id <0K4R00901HNZTI00@fe-emea-09.sun.com> (original mail from Darren.Moffat@Sun.COM) for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Tue, 29 Jul 2008 10:45:08 +0100 (BST) Received: from [129.156.173.21] by fe-emea-09.sun.com (Sun Java System Messaging Server 6.2-8.04 (built Feb 28 2007)) with ESMTPSA id <0K4R00K59HQYCVB0@fe-emea-09.sun.com> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Tue, 29 Jul 2008 10:44:59 +0100 (BST) Date: Tue, 29 Jul 2008 10:44:58 +0100 From: Darren J Moffat Subject: Re: EOF of Cache FileSystem (cachefs) [PSARC/2008/478 FastTrack timeout 08/04/2008] In-reply-to: <488E5372.2070401@Egenera.COM> Sender: Darren.Moffat@sun.com To: Kyle McDonald Cc: "Garrett D'Amore" , Daniel Hain , PSARC-ext@sun.com, Nagakiran.Rajashekar@sun.com Message-id: <488EE69A.2050601@Sun.COM> MIME-version: 1.0 Content-type: text/plain; format=flowed; charset=ISO-8859-1 Content-transfer-encoding: 7BIT X-PMX-Version: 5.4.1.325704 References: <488E141C.9060003@sun.com> <488E201D.1070004@sun.com> <488E29EB.5080803@Sun.COM> <488E2CB7.4020700@sun.com> <20080728221732.GA25547@Sun.COM> <488E4A8E.8090406@sun.com> <20080728225006.GE25547@Sun.COM> <488E5372.2070401@Egenera.COM> User-Agent: Thunderbird 2.0.0.14 (X11/20080630) Status: RO Content-Length: 1523 Kyle McDonald wrote: > Nicolas Williams wrote: >> I don't. cachefs like behaviour could be useful for CIFS as well (and >> some day WebDAV too, why not, and maybe the AFS community would use the >> infrastructure if available). >> >> The problem with cachefs is that it needs to be a service provided to >> filesystems that filesystems must use explicitly. >> >> > As far as what a replacement for CacheFS might be able to do, I'd like > to see even more of a 'Work Offline' feature than it had in th past. > Nico mentions using it for CIFS, and Allowing the user to select files > to be available all the time (on or offline) is one feature CIFS has had > for a while now, and one I find myslef wishing for often when running > Solaris on a laptop. > > > I've used CacheFS quite a bit in the past (mostly for NFS distribution > of application binaries) and I had planned to use it again in the work > I'm doing now, well on Solaris anyway, my Linux clients won't have it. > If it, or something like it were to ever offer true 'work-offline' (with > or without synchronize on reconnect - useful for r/w, but not needed for > r/o) I'd end up using it all the time. I'm not sure what you think is missing from CacheFS in this area. With disconnected mode you could work completely offline and the writes would be resync'd on reconnection. I used to have my laptop setup that way with my home directory. The main reason for the change was to use ZFS locally on the laptop instead. -- Darren J Moffat From kmcdonald@egenera.com Tue Jul 29 05:28:00 2008 Received: from sunmail4.singapore.sun.com (sunmail4.Singapore.Sun.COM [129.158.71.19]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id m6TCRxwM028782 for ; Tue, 29 Jul 2008 05:28:00 -0700 (PDT) Received: from brm-avmta-1.central.sun.com (brm-avmta-1.Central.Sun.COM [129.147.4.11]) by sunmail4.singapore.sun.com (8.13.4+Sun/8.13.3/ENSMAIL,v2.2) with ESMTP id m6TCRg5g029568; Tue, 29 Jul 2008 20:27:53 +0800 (SGT) Received: from pmxchannel-daemon.brm-avmta-1.central.sun.com by brm-avmta-1.central.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0K4R00J05PAD9Z00@brm-avmta-1.central.sun.com>; Tue, 29 Jul 2008 06:27:49 -0600 (MDT) Received: from sca-ea-mail-1.sun.com ([192.18.43.24]) by brm-avmta-1.central.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0K4R004E0PACGZ80@brm-avmta-1.central.sun.com>; Tue, 29 Jul 2008 06:27:48 -0600 (MDT) Received: from relay17i.sun.com (ip127.net129179-4.block1.us.syntegra.com [129.179.4.127]) by sca-ea-mail-1.sun.com (8.13.7+Sun/8.12.9) with ESMTP id m6TCRl0b020688; Tue, 29 Jul 2008 12:27:48 +0000 (GMT) Received: from mmp13es.mmp.us.syntegra.com ([160.41.208.13] [160.41.208.13]) by relay17i.sun.com with ESMTP id BT-MMP-425076; Tue, 29 Jul 2008 12:27:47 +0000 (Z) Received: from relay15i.sun.com (relay15i.sun.com [129.179.4.125]) by mmp13es.mmp.us.syntegra.com with ESMTP id BT-MMP-257276; Tue, 29 Jul 2008 12:27:47 +0000 (Z) Received: from webaccess.egenera.com ([63.139.209.15] [63.139.209.15]) by relay1ib.sun.com with ESMTP id BT-MMP-2786872; Tue, 29 Jul 2008 12:27:47 +0000 (Z) Received: from [192.168.101.160] ([24.107.237.206]) by webaccess.egenera.com over TLS secured channel with Microsoft SMTPSVC(6.0.3790.3959); Tue, 29 Jul 2008 08:29:25 -0400 Date: Tue, 29 Jul 2008 08:29:19 -0400 From: Kyle McDonald Subject: Re: EOF of Cache FileSystem (cachefs) [PSARC/2008/478 FastTrack timeout 08/04/2008] In-reply-to: <488EE69A.2050601@Sun.COM> To: Darren J Moffat Cc: "Garrett D'Amore" , Daniel Hain , PSARC-ext@sun.com, Nagakiran.Rajashekar@sun.com Message-id: <488F0D1F.9090809@Egenera.COM> MIME-version: 1.0 Content-type: text/plain; charset=ISO-8859-1; format=flowed Content-transfer-encoding: 7BIT X-PMX-Version: 5.4.1.325704 X-Brightmail-Tracker: AAAAAA== X-Antispam: No, score=0.0/5.0, scanned in 0.064sec at (localhost [127.0.0.1]) by smf-spamd v1.3.1 - http://smfs.sf.net/ References: <488E141C.9060003@sun.com> <488E201D.1070004@sun.com> <488E29EB.5080803@Sun.COM> <488E2CB7.4020700@sun.com> <20080728221732.GA25547@Sun.COM> <488E4A8E.8090406@sun.com> <20080728225006.GE25547@Sun.COM> <488E5372.2070401@Egenera.COM> <488EE69A.2050601@Sun.COM> User-Agent: Thunderbird 2.0.0.16 (Windows/20080708) X-OriginalArrivalTime: 29 Jul 2008 12:29:25.0391 (UTC) FILETIME=[BCAC69F0:01C8F176] Status: RO Content-Length: 1998 Darren J Moffat wrote: > Kyle McDonald wrote: >> Nicolas Williams wrote: >>> I don't. cachefs like behaviour could be useful for CIFS as well (and >>> some day WebDAV too, why not, and maybe the AFS community would use the >>> infrastructure if available). >>> >>> The problem with cachefs is that it needs to be a service provided to >>> filesystems that filesystems must use explicitly. >>> >>> >> As far as what a replacement for CacheFS might be able to do, I'd >> like to see even more of a 'Work Offline' feature than it had in th >> past. Nico mentions using it for CIFS, and Allowing the user to >> select files to be available all the time (on or offline) is one >> feature CIFS has had for a while now, and one I find myslef wishing >> for often when running Solaris on a laptop. >> >> >> I've used CacheFS quite a bit in the past (mostly for NFS >> distribution of application binaries) and I had planned to use it >> again in the work I'm doing now, well on Solaris anyway, my Linux >> clients won't have it. If it, or something like it were to ever offer >> true 'work-offline' (with or without synchronize on reconnect - >> useful for r/w, but not needed for r/o) I'd end up using it all the >> time. > > I'm not sure what you think is missing from CacheFS in this area. > With disconnected mode you could work completely offline and the > writes would be resync'd on reconnection. I used to have my laptop > setup that way with my home directory. The main reason for the change > was to use ZFS locally on the laptop instead. > Maybe I missed something while i was out of the loop. But it still doesn't sound like you can select on a file or directory basis which items on the filesystem to make available off line (allowing the other to disappear when offline,) can you? Also how is the resync managed? what happens when both have changed? was there a UI that pops up asking which to keep, or for known filetypes, prompting you to merge them? -Kyle From Darren.Moffat@sun.com Tue Jul 29 05:36:27 2008 Received: from sunmail5.uk.sun.com (sunmail5.UK.Sun.COM [129.156.85.165]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id m6TCaQ8s028906 for ; Tue, 29 Jul 2008 05:36:27 -0700 (PDT) Received: from nwk-avmta-2.sfbay.sun.com (nwk-avmta-2.SFBay.Sun.COM [129.145.155.6]) by sunmail5.uk.sun.com (8.13.8+Sun/8.13.8/ENSMAIL,v2.2) with ESMTP id m6TCaOZs026774 for <@sunmail2sca.sfbay.sun.com:PSARC-ext@sun.com>; Tue, 29 Jul 2008 13:36:26 +0100 (BST) Received: from pmxchannel-daemon.nwk-avmta-2.sfbay.sun.com by nwk-avmta-2.sfbay.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0K4R00303POPNC00@nwk-avmta-2.sfbay.sun.com> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Tue, 29 Jul 2008 05:36:25 -0700 (PDT) Received: from gmp-eb-inf-1.sun.com ([192.18.6.21]) by nwk-avmta-2.sfbay.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0K4R00IX7PON9J60@nwk-avmta-2.sfbay.sun.com> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Tue, 29 Jul 2008 05:36:24 -0700 (PDT) Received: from fe-emea-09.sun.com (gmp-eb-lb-2-fe1.eu.sun.com [192.18.6.10]) by gmp-eb-inf-1.sun.com (8.13.7+Sun/8.12.9) with ESMTP id m6TCaNWG023070 for ; Tue, 29 Jul 2008 12:36:23 +0000 (GMT) Received: from conversion-daemon.fe-emea-09.sun.com by fe-emea-09.sun.com (Sun Java System Messaging Server 6.2-8.04 (built Feb 28 2007)) id <0K4R00J01PHY3200@fe-emea-09.sun.com> (original mail from Darren.Moffat@Sun.COM) for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Tue, 29 Jul 2008 13:36:23 +0100 (BST) Received: from [129.156.173.21] by fe-emea-09.sun.com (Sun Java System Messaging Server 6.2-8.04 (built Feb 28 2007)) with ESMTPSA id <0K4R00I9RPOJ0E40@fe-emea-09.sun.com> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Tue, 29 Jul 2008 13:36:20 +0100 (BST) Date: Tue, 29 Jul 2008 13:36:19 +0100 From: Darren J Moffat Subject: Re: EOF of Cache FileSystem (cachefs) [PSARC/2008/478 FastTrack timeout 08/04/2008] In-reply-to: <488F0D1F.9090809@Egenera.COM> Sender: Darren.Moffat@sun.com To: Kyle McDonald Cc: "Garrett D'Amore" , Daniel Hain , PSARC-ext@sun.com, Nagakiran.Rajashekar@sun.com Message-id: <488F0EC3.5030403@Sun.COM> MIME-version: 1.0 Content-type: text/plain; format=flowed; charset=ISO-8859-1 Content-transfer-encoding: 7BIT X-PMX-Version: 5.4.1.325704 References: <488E141C.9060003@sun.com> <488E201D.1070004@sun.com> <488E29EB.5080803@Sun.COM> <488E2CB7.4020700@sun.com> <20080728221732.GA25547@Sun.COM> <488E4A8E.8090406@sun.com> <20080728225006.GE25547@Sun.COM> <488E5372.2070401@Egenera.COM> <488EE69A.2050601@Sun.COM> <488F0D1F.9090809@Egenera.COM> User-Agent: Thunderbird 2.0.0.14 (X11/20080630) Status: RO Content-Length: 1303 Kyle McDonald wrote: >> I'm not sure what you think is missing from CacheFS in this area. >> With disconnected mode you could work completely offline and the >> writes would be resync'd on reconnection. I used to have my laptop >> setup that way with my home directory. The main reason for the change >> was to use ZFS locally on the laptop instead. >> > Maybe I missed something while i was out of the loop. But it still > doesn't sound like you can select on a file or directory basis which > items on the filesystem to make available off line (allowing the other > to disappear when offline,) can you? Yes, cachefspack(1M) and to a much lesser extent cfsadmin(1M). > Also how is the resync managed? what happens when both have changed? was > there a UI that pops up asking which to keep, or for known filetypes, > prompting you to merge them? No merging UI, if that is the model you want you can use filesync(1) which uses the same format of input file as cachefspack(1M). I can't actually remember what happens when the file is changed in both places. The design centre for disconnected mode with write back was AutoClient root file systems so their wouldn't likely have been a change to the filesystem from another NFS client or on the NFS server anyway. -- Darren J Moffat From Darren.Moffat@sun.com Tue Jul 29 05:41:39 2008 Received: from newsunmail1brm.central.sun.com (newsunmail1brm.Central.Sun.COM [129.147.62.245]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id m6TCfdt2028922 for ; Tue, 29 Jul 2008 05:41:39 -0700 (PDT) Received: from nwk-avmta-1.SFBay.Sun.COM (nwk-avmta-1.SFBay.Sun.COM [129.146.11.74]) by newsunmail1brm.central.sun.com (8.13.7+Sun/8.13.7/ENSMAIL,v2.2) with ESMTP id m6TCfaVJ006036 for <@sunmail2sca.sfbay.sun.com:PSARC-ext@sun.com>; Tue, 29 Jul 2008 06:41:39 -0600 (MDT) Received: from pmxchannel-daemon.nwk-avmta-1.sfbay.Sun.COM by nwk-avmta-1.sfbay.Sun.COM (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0K4R00B0PPXDCH00@nwk-avmta-1.sfbay.Sun.COM> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Tue, 29 Jul 2008 05:41:37 -0700 (PDT) Received: from gmp-eb-inf-1.sun.com ([192.18.6.21]) by nwk-avmta-1.sfbay.Sun.COM (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0K4R00LARPX6KLF0@nwk-avmta-1.sfbay.Sun.COM> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Tue, 29 Jul 2008 05:41:31 -0700 (PDT) Received: from fe-emea-10.sun.com (gmp-eb-lb-2-fe3.eu.sun.com [192.18.6.12]) by gmp-eb-inf-1.sun.com (8.13.7+Sun/8.12.9) with ESMTP id m6TCfU9m024478 for ; Tue, 29 Jul 2008 12:41:30 +0000 (GMT) Received: from conversion-daemon.fe-emea-10.sun.com by fe-emea-10.sun.com (Sun Java System Messaging Server 6.2-8.04 (built Feb 28 2007)) id <0K4R00H01PGC5L00@fe-emea-10.sun.com> (original mail from Darren.Moffat@Sun.COM) for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Tue, 29 Jul 2008 13:41:30 +0100 (BST) Received: from [129.156.173.21] by fe-emea-10.sun.com (Sun Java System Messaging Server 6.2-8.04 (built Feb 28 2007)) with ESMTPSA id <0K4R00I72PX0Y640@fe-emea-10.sun.com> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Tue, 29 Jul 2008 13:41:24 +0100 (BST) Date: Tue, 29 Jul 2008 13:41:24 +0100 From: Darren J Moffat Subject: Re: EOF of Cache FileSystem (cachefs) [PSARC/2008/478 FastTrack timeout 08/04/2008] In-reply-to: <488F0D1F.9090809@Egenera.COM> Sender: Darren.Moffat@sun.com To: PSARC-ext@sun.com Cc: Daniel Hain , Nagakiran.Rajashekar@sun.com Message-id: <488F0FF4.3030907@Sun.COM> MIME-version: 1.0 Content-type: text/plain; format=flowed; charset=ISO-8859-1 Content-transfer-encoding: 7BIT X-PMX-Version: 5.4.1.325704 References: <488E141C.9060003@sun.com> <488E201D.1070004@sun.com> <488E29EB.5080803@Sun.COM> <488E2CB7.4020700@sun.com> <20080728221732.GA25547@Sun.COM> <488E4A8E.8090406@sun.com> <20080728225006.GE25547@Sun.COM> <488E5372.2070401@Egenera.COM> <488EE69A.2050601@Sun.COM> <488F0D1F.9090809@Egenera.COM> User-Agent: Thunderbird 2.0.0.14 (X11/20080630) Status: RO Content-Length: 306 Note that the filesync(1) utility while it shares no code with cachefs does share a file format. It has its own implmentation of the parsing routines for the packingrules(4) format files. If this case is approved and when CacheFS is removed the packingrules(4) man page must stay. -- Darren J Moffat From Daniel.Hain@sun.com Thu Jul 31 15:46:04 2008 Received: from sunmail3mpk.sfbay.sun.com (sunmail3mpk.SFBay.Sun.COM [129.146.11.52]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id m6VMk4ix024915 for ; Thu, 31 Jul 2008 15:46:04 -0700 (PDT) Received: from nwk-avmta-2.sfbay.sun.com (nwk-avmta-2.SFBay.Sun.COM [129.145.155.6]) by sunmail3mpk.sfbay.sun.com (8.13.7+Sun/8.13.7/ENSMAIL,v2.2) with ESMTP id m6VMk3PZ025755; Thu, 31 Jul 2008 15:46:04 -0700 (PDT) Received: from pmxchannel-daemon.nwk-avmta-2.sfbay.sun.com by nwk-avmta-2.sfbay.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0K4W00E0P78RUT00@nwk-avmta-2.sfbay.sun.com>; Thu, 31 Jul 2008 15:46:03 -0700 (PDT) Received: from sca-es-mail-1.sun.com ([192.18.43.132]) by nwk-avmta-2.sfbay.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0K4W00CJ778PLY40@nwk-avmta-2.sfbay.sun.com>; Thu, 31 Jul 2008 15:46:01 -0700 (PDT) Received: from fe-sfbay-10.sun.com ([192.18.43.129]) by sca-es-mail-1.sun.com (8.13.7+Sun/8.12.9) with ESMTP id m6VMk1m2015264; Thu, 31 Jul 2008 15:46:01 -0700 (PDT) Received: from conversion-daemon.fe-sfbay-10.sun.com by fe-sfbay-10.sun.com (Sun Java System Messaging Server 6.2-8.04 (built Feb 28 2007)) id <0K4W00J01705M600@fe-sfbay-10.sun.com> (original mail from Daniel.Hain@Sun.COM); Thu, 31 Jul 2008 15:46:01 -0700 (PDT) Received: from [129.153.88.154] by fe-sfbay-10.sun.com (Sun Java System Messaging Server 6.2-8.04 (built Feb 28 2007)) with ESMTPSA id <0K4W00IUF78NNYF0@fe-sfbay-10.sun.com>; Thu, 31 Jul 2008 15:46:00 -0700 (PDT) Date: Thu, 31 Jul 2008 15:46:19 -0700 From: Daniel Hain Subject: Re: EOF of Cache FileSystem (cachefs) [PSARC/2008/478 FastTrack timeout 08/04/2008] In-reply-to: <488E257B.90900@sun.com> Sender: Daniel.Hain@sun.com To: psarc-ext@sun.com Cc: "Nagakiran K.R" , Ebru Williams , cachefs-eof-discuss@sun.com Message-id: <489240BB.5060809@sun.com> MIME-version: 1.0 Content-type: text/plain; format=flowed; charset=ISO-8859-1 Content-transfer-encoding: 7BIT X-PMX-Version: 5.4.1.325704 References: <488E141C.9060003@sun.com> <488E201D.1070004@sun.com> <488E29EB.5080803@Sun.COM> <488E2CB7.4020700@sun.com> <20080728221732.GA25547@Sun.COM> <488E4A8E.8090406@sun.com> <20080728225006.GE25547@Sun.COM> <488E5372.2070401@Egenera.COM> <488ed583.NWaDBV+/boGUWNyI%Joerg.Schilling@fokus.fraunhofer.de> <488E257B.90900@sun.com> User-Agent: Thunderbird 2.0.0.12 (X11/20080310) Status: RO Content-Length: 1346 I've been informed that the project team has an Aug 6 deadline for providing EOF materials to Marketing and Docs, pending resolution of this case (timeout on 8/4). I would like to summarize where I think we are so that the project team can address any issues between now and when the case times out. Issue: Client side caching in our NFSv4: how this gap will be filled, or why it isn't necessary. There has been some discussion about migrating to NFSv4+ZFS, but it was unclear as to whether that was sufficient. Issue: Provide a local persistent cache feature, or commitment to do so. Some good discussion of why such a feature would be nice, but it was not clear if this was a requirement for moving forward with the EOF. Please let me know if I missed something. -- Dan Hain Solaris Revenue Product Engineering (RPE) From Darren.Moffat@sun.com Fri Aug 1 01:57:37 2008 Received: from sunmail4.singapore.sun.com (sunmail4.Singapore.Sun.COM [129.158.71.19]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id m718vada009752 for ; Fri, 1 Aug 2008 01:57:36 -0700 (PDT) Received: from nwk-avmta-1.SFBay.Sun.COM (nwk-avmta-1.SFBay.Sun.COM [129.146.11.74]) by sunmail4.singapore.sun.com (8.13.4+Sun/8.13.3/ENSMAIL,v2.2) with ESMTP id m718vXY7019815; Fri, 1 Aug 2008 16:57:35 +0800 (SGT) Received: from pmxchannel-daemon.nwk-avmta-1.sfbay.Sun.COM by nwk-avmta-1.sfbay.Sun.COM (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0K4W00I01ZJXG800@nwk-avmta-1.sfbay.Sun.COM>; Fri, 01 Aug 2008 01:57:33 -0700 (PDT) Received: from gmp-eb-inf-1.sun.com ([192.18.6.21]) by nwk-avmta-1.sfbay.Sun.COM (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0K4W00CJMZJWW220@nwk-avmta-1.sfbay.Sun.COM>; Fri, 01 Aug 2008 01:57:33 -0700 (PDT) Received: from fe-emea-10.sun.com (gmp-eb-lb-2-fe1.eu.sun.com [192.18.6.10]) by gmp-eb-inf-1.sun.com (8.13.7+Sun/8.12.9) with ESMTP id m718vWvD029058; Fri, 01 Aug 2008 08:57:32 +0000 (GMT) Received: from conversion-daemon.fe-emea-10.sun.com by fe-emea-10.sun.com (Sun Java System Messaging Server 6.2-8.04 (built Feb 28 2007)) id <0K4W00301YUFV900@fe-emea-10.sun.com> (original mail from Darren.Moffat@Sun.COM); Fri, 01 Aug 2008 09:57:32 +0100 (BST) Received: from [129.156.173.21] by fe-emea-10.sun.com (Sun Java System Messaging Server 6.2-8.04 (built Feb 28 2007)) with ESMTPSA id <0K4W000DXZJK5C90@fe-emea-10.sun.com>; Fri, 01 Aug 2008 09:57:21 +0100 (BST) Date: Fri, 01 Aug 2008 09:57:20 +0100 From: Darren J Moffat Subject: Re: EOF of Cache FileSystem (cachefs) [PSARC/2008/478 FastTrack timeout 08/04/2008] In-reply-to: <489240BB.5060809@sun.com> Sender: Darren.Moffat@sun.com To: Daniel Hain Cc: psarc-ext@sun.com, "Nagakiran K.R" , Ebru Williams , cachefs-eof-discuss@sun.com Message-id: <4892CFF0.7060003@Sun.COM> MIME-version: 1.0 Content-type: text/plain; format=flowed; charset=ISO-8859-1 Content-transfer-encoding: 7BIT X-PMX-Version: 5.4.1.325704 References: <488E141C.9060003@sun.com> <488E201D.1070004@sun.com> <488E29EB.5080803@Sun.COM> <488E2CB7.4020700@sun.com> <20080728221732.GA25547@Sun.COM> <488E4A8E.8090406@sun.com> <20080728225006.GE25547@Sun.COM> <488E5372.2070401@Egenera.COM> <488ed583.NWaDBV+/boGUWNyI%Joerg.Schilling@fokus.fraunhofer.de> <488E257B.90900@sun.com> <489240BB.5060809@sun.com> User-Agent: Thunderbird 2.0.0.14 (X11/20080630) Status: RO Content-Length: 1018 Daniel Hain wrote: > I've been informed that the project team has an Aug 6 deadline for > providing EOF materials to Marketing and Docs, pending resolution of > this case (timeout on 8/4). I would like to summarize where I think we > are so that the project team can address any issues between now and when > the case times out. > > Issue: Client side caching in our NFSv4: how this gap will be filled, > or why it isn't necessary. There has been some discussion about > migrating to NFSv4+ZFS, but it was unclear as to whether that was > sufficient. > > Issue: Provide a local persistent cache feature, or commitment to do > so. Some good discussion of why such a feature would be nice, but it > was not clear if this was a requirement for moving forward with the EOF. I think this case needs a formal opinion. I'm derailing it an will happily provide the opinion text (as either majority or minority). Do other ARC members wish to vote now or when they see a draft opinion ? -- Darren J Moffat From Frank.Batschulat@sun.com Fri Aug 1 02:22:44 2008 Received: from sunmail5.uk.sun.com (sunmail5.UK.Sun.COM [129.156.85.165]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id m719Mh1j011982 for ; Fri, 1 Aug 2008 02:22:43 -0700 (PDT) Received: from nwk-avmta-2.sfbay.sun.com (nwk-avmta-2.SFBay.Sun.COM [129.145.155.6]) by sunmail5.uk.sun.com (8.13.8+Sun/8.13.8/ENSMAIL,v2.2) with ESMTP id m719McII006417; Fri, 1 Aug 2008 10:22:41 +0100 (BST) Received: from pmxchannel-daemon.nwk-avmta-2.sfbay.sun.com by nwk-avmta-2.sfbay.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0K4X00M2N0PQFB00@nwk-avmta-2.sfbay.sun.com>; Fri, 01 Aug 2008 02:22:38 -0700 (PDT) Received: from gmp-eb-inf-1.sun.com ([192.18.6.21]) by nwk-avmta-2.sfbay.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0K4X00MQD0PN5Q20@nwk-avmta-2.sfbay.sun.com>; Fri, 01 Aug 2008 02:22:35 -0700 (PDT) Received: from fe-emea-09.sun.com (gmp-eb-lb-2-fe3.eu.sun.com [192.18.6.12]) by gmp-eb-inf-1.sun.com (8.13.7+Sun/8.12.9) with ESMTP id m719MYk1006219; Fri, 01 Aug 2008 09:22:34 +0000 (GMT) Received: from conversion-daemon.fe-emea-09.sun.com by fe-emea-09.sun.com (Sun Java System Messaging Server 6.2-8.04 (built Feb 28 2007)) id <0K4X005010KE9I00@fe-emea-09.sun.com> (original mail from Frank.Batschulat@Sun.COM); Fri, 01 Aug 2008 10:22:34 +0100 (BST) Received: from opteron ([84.188.233.79]) by fe-emea-09.sun.com (Sun Java System Messaging Server 6.2-8.04 (built Feb 28 2007)) with ESMTPSA id <0K4X003FQ0PK1UE0@fe-emea-09.sun.com>; Fri, 01 Aug 2008 10:22:34 +0100 (BST) Date: Fri, 01 Aug 2008 11:21:16 +0200 From: "Frank Batschulat (Home)" Subject: Re: EOF of Cache FileSystem (cachefs) [PSARC/2008/478 FastTrack timeout 08/04/2008] In-reply-to: <4892CFF0.7060003@Sun.COM> Sender: Frank.Batschulat@sun.com To: Darren J Moffat , Daniel Hain Cc: psarc-ext@sun.com, "Nagakiran K.R" , Ebru Williams , cachefs-eof-discuss@sun.com Message-id: Organization: SUN Microsystems MIME-version: 1.0 Content-type: text/plain; charset=utf-8 Content-transfer-encoding: 7BIT X-PMX-Version: 5.4.1.325704 References: <488E141C.9060003@sun.com> <488E201D.1070004@sun.com> <488E29EB.5080803@Sun.COM> <488E2CB7.4020700@sun.com> <20080728221732.GA25547@Sun.COM> <488E4A8E.8090406@sun.com> <20080728225006.GE25547@Sun.COM> <488E5372.2070401@Egenera.COM> <488ed583.NWaDBV+/boGUWNyI%Joerg.Schilling@fokus.fraunhofer.de> <488E257B.90900@sun.com> <489240BB.5060809@sun.com> <4892CFF0.7060003@Sun.COM> User-Agent: Opera Mail/9.27 (SunOS) Status: RO Content-Length: 644 On Fri, 01 Aug 2008 10:57:20 +0200, Darren J Moffat wrote: > I think this case needs a formal opinion. I'm derailing it an will > happily provide the opinion text (as either majority or minority). > > Do other ARC members wish to vote now or when they see a draft opinion ? I'd hope and expect this opinion will contain a reasonable proposal for the future how the arc expects to deal with such situations in general. sooner or later, psarc has to face the fact that old, dead, out of development products and features have to and will be EOF/EOF'ed, no matter if there is a replacement or not. regards --- frankB From Darren.Moffat@sun.com Fri Aug 1 02:30:04 2008 Received: from sunmail4.singapore.sun.com (sunmail4.Singapore.Sun.COM [129.158.71.19]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id m719U3LS012125 for ; Fri, 1 Aug 2008 02:30:04 -0700 (PDT) Received: from nwk-avmta-2.sfbay.sun.com (nwk-avmta-2.SFBay.Sun.COM [129.145.155.6]) by sunmail4.singapore.sun.com (8.13.4+Sun/8.13.3/ENSMAIL,v2.2) with ESMTP id m719TpAB003098; Fri, 1 Aug 2008 17:30:02 +0800 (SGT) Received: from pmxchannel-daemon.nwk-avmta-2.sfbay.sun.com by nwk-avmta-2.sfbay.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0K4X00M0F120OR00@nwk-avmta-2.sfbay.sun.com>; Fri, 01 Aug 2008 02:30:00 -0700 (PDT) Received: from gmp-eb-inf-1.sun.com ([192.18.6.21]) by nwk-avmta-2.sfbay.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0K4X00MFF11Z5Q40@nwk-avmta-2.sfbay.sun.com>; Fri, 01 Aug 2008 02:29:59 -0700 (PDT) Received: from fe-emea-10.sun.com (gmp-eb-lb-2-fe3.eu.sun.com [192.18.6.12]) by gmp-eb-inf-1.sun.com (8.13.7+Sun/8.12.9) with ESMTP id m719TwPg008379; Fri, 01 Aug 2008 09:29:58 +0000 (GMT) Received: from conversion-daemon.fe-emea-10.sun.com by fe-emea-10.sun.com (Sun Java System Messaging Server 6.2-8.04 (built Feb 28 2007)) id <0K4W00H01ZVJR200@fe-emea-10.sun.com> (original mail from Darren.Moffat@Sun.COM); Fri, 01 Aug 2008 10:29:58 +0100 (BST) Received: from [129.156.173.21] by fe-emea-10.sun.com (Sun Java System Messaging Server 6.2-8.04 (built Feb 28 2007)) with ESMTPSA id <0K4X000ZZ11O5CA0@fe-emea-10.sun.com>; Fri, 01 Aug 2008 10:29:50 +0100 (BST) Date: Fri, 01 Aug 2008 10:29:48 +0100 From: Darren J Moffat Subject: Re: EOF of Cache FileSystem (cachefs) [PSARC/2008/478 FastTrack timeout 08/04/2008] In-reply-to: Sender: Darren.Moffat@sun.com To: "Frank Batschulat (Home)" Cc: Daniel Hain , psarc-ext@sun.com, "Nagakiran K.R" , Ebru Williams , cachefs-eof-discuss@sun.com Message-id: <4892D78C.1040502@Sun.COM> MIME-version: 1.0 Content-type: text/plain; format=flowed; charset=UTF-8 Content-transfer-encoding: 7BIT X-PMX-Version: 5.4.1.325704 References: <488E141C.9060003@sun.com> <488E201D.1070004@sun.com> <488E29EB.5080803@Sun.COM> <488E2CB7.4020700@sun.com> <20080728221732.GA25547@Sun.COM> <488E4A8E.8090406@sun.com> <20080728225006.GE25547@Sun.COM> <488E5372.2070401@Egenera.COM> <488ed583.NWaDBV+/boGUWNyI%Joerg.Schilling@fokus.fraunhofer.de> <488E257B.90900@sun.com> <489240BB.5060809@sun.com> <4892CFF0.7060003@Sun.COM> User-Agent: Thunderbird 2.0.0.14 (X11/20080630) Status: RO Content-Length: 1416 Frank Batschulat (Home) wrote: > On Fri, 01 Aug 2008 10:57:20 +0200, Darren J Moffat wrote: > >> I think this case needs a formal opinion. I'm derailing it an will >> happily provide the opinion text (as either majority or minority). >> >> Do other ARC members wish to vote now or when they see a draft opinion ? > > I'd hope and expect this opinion will contain a reasonable proposal for the future how > the arc expects to deal with such situations in general. Not from me it won't. If you wish to provide such text I'd be happy to include it in the opinion for review. > sooner or later, psarc has to face the fact that old, dead, out of development products > and features have to and will be EOF/EOF'ed, no matter if there is a replacement or not. That is more of a business issue. The job of the ARC is to review the change to the architecture and if it feels necessary point out gaps/issues to the business side of the process. That is exactly what I'm doing here. There is a HUGE difference between wanting to EOF the particular implementation of a feature and no longer requiring the functionality at all. As I've already said I support the EOF of the CacheFS code base what I don't support is the fact that we have no equivalent for NFSv4 and CIFS and I believe that we need one (not least of which because there are competitive offerings). -- Darren J Moffat From gdamore@sun.com Fri Aug 1 08:31:15 2008 Received: from sunmail5.uk.sun.com (sunmail5.UK.Sun.COM [129.156.85.165]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id m71FVErY021971 for ; Fri, 1 Aug 2008 08:31:15 -0700 (PDT) Received: from nwk-avmta-1.SFBay.Sun.COM (nwk-avmta-1.SFBay.Sun.COM [129.146.11.74]) by sunmail5.uk.sun.com (8.13.8+Sun/8.13.8/ENSMAIL,v2.2) with ESMTP id m71FVBt2026272; Fri, 1 Aug 2008 16:31:13 +0100 (BST) Received: from pmxchannel-daemon.nwk-avmta-1.sfbay.Sun.COM by nwk-avmta-1.sfbay.Sun.COM (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0K4X00C7PHS0KB00@nwk-avmta-1.sfbay.Sun.COM>; Fri, 01 Aug 2008 08:31:12 -0700 (PDT) Received: from sca-es-mail-1.sun.com ([192.18.43.132]) by nwk-avmta-1.sfbay.Sun.COM (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0K4X005OPHRH2D60@nwk-avmta-1.sfbay.Sun.COM>; Fri, 01 Aug 2008 08:30:53 -0700 (PDT) Received: from fe-sfbay-09.sun.com ([192.18.43.129]) by sca-es-mail-1.sun.com (8.13.7+Sun/8.12.9) with ESMTP id m71FUrDl026530; Fri, 01 Aug 2008 08:30:53 -0700 (PDT) Received: from conversion-daemon.fe-sfbay-09.sun.com by fe-sfbay-09.sun.com (Sun Java System Messaging Server 6.2-8.04 (built Feb 28 2007)) id <0K4X00A01HIMDZ00@fe-sfbay-09.sun.com> (original mail from gdamore@sun.com) ; Fri, 01 Aug 2008 08:30:53 -0700 (PDT) Received: from [10.7.251.172] by fe-sfbay-09.sun.com (Sun Java System Messaging Server 6.2-8.04 (built Feb 28 2007)) with ESMTPSA id <0K4X00LHWHR7UT50@fe-sfbay-09.sun.com>; Fri, 01 Aug 2008 08:30:44 -0700 (PDT) Date: Fri, 01 Aug 2008 08:25:57 -0700 From: "Garrett D'Amore" Subject: Re: EOF of Cache FileSystem (cachefs) [PSARC/2008/478 FastTrack timeout 08/04/2008] In-reply-to: <4892D78C.1040502@Sun.COM> Sender: Garrett.Damore@sun.com To: Darren J Moffat Cc: "Frank Batschulat (Home)" , Daniel Hain , psarc-ext@sun.com, "Nagakiran K.R" , Ebru Williams , cachefs-eof-discuss@sun.com Message-id: <48932B05.50401@sun.com> MIME-version: 1.0 Content-type: text/plain; format=flowed; charset=UTF-8 Content-transfer-encoding: 7BIT X-PMX-Version: 5.4.1.325704 References: <488E141C.9060003@sun.com> <488E201D.1070004@sun.com> <488E29EB.5080803@Sun.COM> <488E2CB7.4020700@sun.com> <20080728221732.GA25547@Sun.COM> <488E4A8E.8090406@sun.com> <20080728225006.GE25547@Sun.COM> <488E5372.2070401@Egenera.COM> <488ed583.NWaDBV+/boGUWNyI%Joerg.Schilling@fokus.fraunhofer.de> <488E257B.90900@sun.com> <489240BB.5060809@sun.com> <4892CFF0.7060003@Sun.COM> <4892D78C.1040502@Sun.COM> User-Agent: Thunderbird 2.0.0.14 (X11/20080616) Status: RO Content-Length: 1818 Darren J Moffat wrote: > Frank Batschulat (Home) wrote: >> On Fri, 01 Aug 2008 10:57:20 +0200, Darren J Moffat >> wrote: >> >>> I think this case needs a formal opinion. I'm derailing it an will >>> happily provide the opinion text (as either majority or minority). >>> >>> Do other ARC members wish to vote now or when they see a draft >>> opinion ? >> >> I'd hope and expect this opinion will contain a reasonable proposal >> for the future how >> the arc expects to deal with such situations in general. > > Not from me it won't. If you wish to provide such text I'd be happy > to include it in the opinion for review. > >> sooner or later, psarc has to face the fact that old, dead, out of >> development products >> and features have to and will be EOF/EOF'ed, no matter if there is a >> replacement or not. > > That is more of a business issue. The job of the ARC is to review the > change to the architecture and if it feels necessary point out > gaps/issues to the business side of the process. That is exactly what > I'm doing here. > > There is a HUGE difference between wanting to EOF the particular > implementation of a feature and no longer requiring the functionality > at all. > > As I've already said I support the EOF of the CacheFS code base what I > don't support is the fact that we have no equivalent for NFSv4 and > CIFS and I believe that we need one (not least of which because there > are competitive offerings). > I"d be willing to vote to approve now, provided the opinion states the desire for a replacement that provides caching for NFSv4 at least (and CIFS would indeed be a nice feature to have.) Perhaps this is a TCA. I'm also happy to vote to approve if the opinion states the same thing as a requirement (TCR) instead. -- Garrett From Gordon.Ross@sun.com Mon Aug 4 13:32:45 2008 Received: from sunmail5.uk.sun.com (sunmail5.UK.Sun.COM [129.156.85.165]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id m74KWikO000041 for ; Mon, 4 Aug 2008 13:32:45 -0700 (PDT) Received: from nwk-avmta-2.sfbay.sun.com (nwk-avmta-2.SFBay.Sun.COM [129.145.155.6]) by sunmail5.uk.sun.com (8.13.8+Sun/8.13.8/ENSMAIL,v2.2) with ESMTP id m74KWXa9010447 for <@sunmail2sca.sfbay.sun.com:PSARC-ext@sun.com>; Mon, 4 Aug 2008 21:32:44 +0100 (BST) Received: from pmxchannel-daemon.nwk-avmta-2.sfbay.sun.com by nwk-avmta-2.sfbay.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0K5300A05FQHRJ00@nwk-avmta-2.sfbay.sun.com> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Mon, 04 Aug 2008 13:32:41 -0700 (PDT) Received: from brmea-mail-1.sun.com ([192.18.98.31]) by nwk-avmta-2.sfbay.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0K5300AHWFQG6R10@nwk-avmta-2.sfbay.sun.com> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Mon, 04 Aug 2008 13:32:41 -0700 (PDT) Received: from fe-amer-09.sun.com ([192.18.109.79]) by brmea-mail-1.sun.com (8.13.6+Sun/8.12.9) with ESMTP id m74KWe3K006717 for ; Mon, 04 Aug 2008 20:32:40 +0000 (GMT) Received: from conversion-daemon.mail-amer.sun.com by mail-amer.sun.com (Sun Java System Messaging Server 6.2-8.04 (built Feb 28 2007)) id <0K5300401FF8KU00@mail-amer.sun.com> (original mail from Gordon.Ross@Sun.COM) for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Mon, 04 Aug 2008 14:32:40 -0600 (MDT) Received: from [192.168.1.4] ([75.67.12.95]) by mail-amer.sun.com (Sun Java System Messaging Server 6.2-8.04 (built Feb 28 2007)) with ESMTPSA id <0K53003OHFQFED80@mail-amer.sun.com> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Mon, 04 Aug 2008 14:32:40 -0600 (MDT) Date: Mon, 04 Aug 2008 16:32:35 -0400 From: Gordon Ross Subject: Re: EOF of Cache FileSystem (cachefs) [PSARC/2008/478 FastTrack timeout 08/04/2008] In-reply-to: <488E4A8E.8090406@sun.com> Sender: Gordon.Ross@sun.com To: "Garrett D'Amore" Cc: PSARC-ext@sun.com Message-id: <1217881955.1728.51.camel@acer-gwr> MIME-version: 1.0 X-Mailer: Evolution 2.22.2 Content-type: text/plain Content-transfer-encoding: 8BIT X-PMX-Version: 5.4.1.325704 References: <488E141C.9060003@sun.com> <488E201D.1070004@sun.com> <488E29EB.5080803@Sun.COM> <488E2CB7.4020700@sun.com> <20080728221732.GA25547@Sun.COM> <488E4A8E.8090406@sun.com> Status: RO Content-Length: 1030 [...] > I'd be happy to see a whitepaper or some kind of transition document > with the case, describing (ideally in terms a customer should be able > to > understand) how to transition from cachefs to some other strategy > (iSCSI, NFSv4, whatever). I don't know how to make the same > functionality (NFS like) work with iSCSI, but I'll chalk that up to > my > own ignorance rather than any deficiency in iSCSI. > > It would be nice to see a commitment to closing any remaining gap as > much as possible, perhaps by further development of NFSv4 -- as > others > have suggested. > > As a final note, I do recall that cachefs was supposed to be generic > for > things like cdroms, etc. I do agree with the proposal that cachefs > like > behavior for anything *other than NFS* is probably not terribly > interesting. Don't forget the "smbfs" client (similar to the NFSv4 client). That suggests the need for a solution above the VFS, or at least one that can can be mostly common among VFS implementations. Gordon From Daniel.Hain@sun.com Tue Aug 5 08:33:24 2008 Received: from sunmail5.uk.sun.com (sunmail5.UK.Sun.COM [129.156.85.165]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id m75FXOwD000840 for ; Tue, 5 Aug 2008 08:33:24 -0700 (PDT) Received: from nwk-avmta-1.SFBay.Sun.COM (nwk-avmta-1.SFBay.Sun.COM [129.146.11.74]) by sunmail5.uk.sun.com (8.13.8+Sun/8.13.8/ENSMAIL,v2.2) with ESMTP id m75FXE5v024029; Tue, 5 Aug 2008 16:33:22 +0100 (BST) Received: from pmxchannel-daemon.nwk-avmta-1.sfbay.Sun.COM by nwk-avmta-1.sfbay.Sun.COM (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0K5400B97WJJYK00@nwk-avmta-1.sfbay.Sun.COM>; Tue, 05 Aug 2008 08:33:19 -0700 (PDT) Received: from sca-es-mail-1.sun.com ([192.18.43.132]) by nwk-avmta-1.sfbay.Sun.COM (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0K54009LUWJD3430@nwk-avmta-1.sfbay.Sun.COM>; Tue, 05 Aug 2008 08:33:13 -0700 (PDT) Received: from fe-sfbay-10.sun.com ([192.18.43.129]) by sca-es-mail-1.sun.com (8.13.7+Sun/8.12.9) with ESMTP id m75FXDto023990; Tue, 05 Aug 2008 08:33:13 -0700 (PDT) Received: from conversion-daemon.fe-sfbay-10.sun.com by fe-sfbay-10.sun.com (Sun Java System Messaging Server 6.2-8.04 (built Feb 28 2007)) id <0K5400M01W5WDT00@fe-sfbay-10.sun.com> (original mail from Daniel.Hain@Sun.COM); Tue, 05 Aug 2008 08:33:13 -0700 (PDT) Received: from [129.153.88.157] by fe-sfbay-10.sun.com (Sun Java System Messaging Server 6.2-8.04 (built Feb 28 2007)) with ESMTPSA id <0K5400FSHWJ8HK50@fe-sfbay-10.sun.com>; Tue, 05 Aug 2008 08:33:08 -0700 (PDT) Date: Tue, 05 Aug 2008 08:33:21 -0700 From: Daniel Hain Subject: Re: EOF of Cache FileSystem (cachefs) [PSARC/2008/478 FastTrack timeout 08/04/2008] In-reply-to: <4892CFF0.7060003@Sun.COM> Sender: Daniel.Hain@sun.com To: psarc-ext@sun.com Cc: "Nagakiran K.R" , Ebru Williams , cachefs-eof-discuss@sun.com Message-id: <489872C1.1000308@sun.com> MIME-version: 1.0 Content-type: text/plain; format=flowed; charset=ISO-8859-1 Content-transfer-encoding: 7BIT X-PMX-Version: 5.4.1.325704 References: <488E141C.9060003@sun.com> <488E201D.1070004@sun.com> <488E29EB.5080803@Sun.COM> <488E2CB7.4020700@sun.com> <20080728221732.GA25547@Sun.COM> <488E4A8E.8090406@sun.com> <20080728225006.GE25547@Sun.COM> <488E5372.2070401@Egenera.COM> <488ed583.NWaDBV+/boGUWNyI%Joerg.Schilling@fokus.fraunhofer.de> <488E257B.90900@sun.com> <489240BB.5060809@sun.com> <4892CFF0.7060003@Sun.COM> User-Agent: Thunderbird 2.0.0.14 (X11/20080630) Status: RO Content-Length: 1768 Darren J Moffat wrote: > Daniel Hain wrote: >> I've been informed that the project team has an Aug 6 deadline for >> providing EOF materials to Marketing and Docs, pending resolution of >> this case (timeout on 8/4). I would like to summarize where I think >> we are so that the project team can address any issues between now >> and when the case times out. >> >> Issue: Client side caching in our NFSv4: how this gap will be >> filled, or why it isn't necessary. There has been some discussion >> about migrating to NFSv4+ZFS, but it was unclear as to whether that >> was sufficient. >> >> Issue: Provide a local persistent cache feature, or commitment to do >> so. Some good discussion of why such a feature would be nice, but it >> was not clear if this was a requirement for moving forward with the EOF. > > I think this case needs a formal opinion. I'm derailing it an will > happily provide the opinion text (as either majority or minority). > > Do other ARC members wish to vote now or when they see a draft opinion ? > I saw 2 votes to approve (Darren and Garrett, thank you) after the derail. How many do we need to allow the project team to continue with the EOF process? -- Dan Hain Solaris Revenue Product Engineering (RPE) http://namefinder/NameFinder?nfquery=-s+88796 From gdamore@sun.com Tue Aug 5 08:45:20 2008 Received: from sunmail4.singapore.sun.com (sunmail4.Singapore.Sun.COM [129.158.71.19]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id m75FjJUr001347 for ; Tue, 5 Aug 2008 08:45:20 -0700 (PDT) Received: from nwk-avmta-1.SFBay.Sun.COM (nwk-avmta-1.SFBay.Sun.COM [129.146.11.74]) by sunmail4.singapore.sun.com (8.13.4+Sun/8.13.3/ENSMAIL,v2.2) with ESMTP id m75FjHbq008043; Tue, 5 Aug 2008 23:45:18 +0800 (SGT) Received: from pmxchannel-daemon.nwk-avmta-1.sfbay.Sun.COM by nwk-avmta-1.sfbay.Sun.COM (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0K5400D01X3I5Y00@nwk-avmta-1.sfbay.Sun.COM>; Tue, 05 Aug 2008 08:45:18 -0700 (PDT) Received: from sca-es-mail-1.sun.com ([192.18.43.132]) by nwk-avmta-1.sfbay.Sun.COM (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0K54009P6X3H3B40@nwk-avmta-1.sfbay.Sun.COM>; Tue, 05 Aug 2008 08:45:17 -0700 (PDT) Received: from fe-sfbay-09.sun.com ([192.18.43.129]) by sca-es-mail-1.sun.com (8.13.7+Sun/8.12.9) with ESMTP id m75FjHC8025438; Tue, 05 Aug 2008 08:45:17 -0700 (PDT) Received: from conversion-daemon.fe-sfbay-09.sun.com by fe-sfbay-09.sun.com (Sun Java System Messaging Server 6.2-8.04 (built Feb 28 2007)) id <0K5400L01WTYMG00@fe-sfbay-09.sun.com> (original mail from gdamore@sun.com) ; Tue, 05 Aug 2008 08:45:17 -0700 (PDT) Received: from [10.7.251.172] by fe-sfbay-09.sun.com (Sun Java System Messaging Server 6.2-8.04 (built Feb 28 2007)) with ESMTPSA id <0K54000N7X3ETU10@fe-sfbay-09.sun.com>; Tue, 05 Aug 2008 08:45:15 -0700 (PDT) Date: Tue, 05 Aug 2008 08:40:09 -0700 From: "Garrett D'Amore" Subject: Re: EOF of Cache FileSystem (cachefs) [PSARC/2008/478 FastTrack timeout 08/04/2008] In-reply-to: <489872C1.1000308@sun.com> Sender: Garrett.Damore@sun.com To: Daniel Hain Cc: psarc-ext@sun.com, "Nagakiran K.R" , Ebru Williams , cachefs-eof-discuss@sun.com Message-id: <48987459.6000302@sun.com> MIME-version: 1.0 Content-type: text/plain; format=flowed; charset=ISO-8859-1 Content-transfer-encoding: 7BIT X-PMX-Version: 5.4.1.325704 References: <488E141C.9060003@sun.com> <488E201D.1070004@sun.com> <488E29EB.5080803@Sun.COM> <488E2CB7.4020700@sun.com> <20080728221732.GA25547@Sun.COM> <488E4A8E.8090406@sun.com> <20080728225006.GE25547@Sun.COM> <488E5372.2070401@Egenera.COM> <488ed583.NWaDBV+/boGUWNyI%Joerg.Schilling@fokus.fraunhofer.de> <488E257B.90900@sun.com> <489240BB.5060809@sun.com> <4892CFF0.7060003@Sun.COM> <489872C1.1000308@sun.com> User-Agent: Thunderbird 2.0.0.14 (X11/20080616) Status: RO Content-Length: 1460 Daniel Hain wrote: > Darren J Moffat wrote: >> Daniel Hain wrote: >>> I've been informed that the project team has an Aug 6 deadline for >>> providing EOF materials to Marketing and Docs, pending resolution of >>> this case (timeout on 8/4). I would like to summarize where I >>> think we are so that the project team can address any issues >>> between now and when the case times out. >>> >>> Issue: Client side caching in our NFSv4: how this gap will be >>> filled, or why it isn't necessary. There has been some discussion >>> about migrating to NFSv4+ZFS, but it was unclear as to whether that >>> was sufficient. >>> >>> Issue: Provide a local persistent cache feature, or commitment to do >>> so. Some good discussion of why such a feature would be nice, but >>> it was not clear if this was a requirement for moving forward with >>> the EOF. >> >> I think this case needs a formal opinion. I'm derailing it an will >> happily provide the opinion text (as either majority or minority). >> >> Do other ARC members wish to vote now or when they see a draft opinion ? >> > > I saw 2 votes to approve (Darren and Garrett, thank you) after the > derail. How many do we need to allow the project team to continue > with the EOF process? I think we need at least a quorum of voters (is that 4 now?) to respond, and a majority of those who've responded. I suspect you'll have a final answer after tomorrow's meeting. -- Garrett > > From Darren.Moffat@sun.com Thu Aug 7 01:40:00 2008 Received: from newsunmail1brm.central.sun.com (newsunmail1brm.Central.Sun.COM [129.147.62.245]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id m778dxJQ015595 for ; Thu, 7 Aug 2008 01:40:00 -0700 (PDT) Received: from nwk-avmta-1.SFBay.Sun.COM (nwk-avmta-1.SFBay.Sun.COM [129.146.11.74]) by newsunmail1brm.central.sun.com (8.13.7+Sun/8.13.7/ENSMAIL,v2.2) with ESMTP id m778dxPU053487; Thu, 7 Aug 2008 02:39:59 -0600 (MDT) Received: from pmxchannel-daemon.nwk-avmta-1.sfbay.Sun.COM by nwk-avmta-1.sfbay.Sun.COM (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0K58007092QLT400@nwk-avmta-1.sfbay.Sun.COM>; Thu, 07 Aug 2008 01:39:57 -0700 (PDT) Received: from gmp-eb-inf-1.sun.com ([192.18.6.21]) by nwk-avmta-1.sfbay.Sun.COM (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0K58000Z92QKAW50@nwk-avmta-1.sfbay.Sun.COM>; Thu, 07 Aug 2008 01:39:56 -0700 (PDT) Received: from fe-emea-10.sun.com (gmp-eb-lb-2-fe3.eu.sun.com [192.18.6.12] (may be forged)) by gmp-eb-inf-1.sun.com (8.13.7+Sun/8.12.9) with ESMTP id m778dts7001800; Thu, 07 Aug 2008 08:39:55 +0000 (GMT) Received: from conversion-daemon.fe-emea-10.sun.com by fe-emea-10.sun.com (Sun Java System Messaging Server 6.2-8.04 (built Feb 28 2007)) id <0K5800J012NJ2200@fe-emea-10.sun.com> (original mail from Darren.Moffat@Sun.COM); Thu, 07 Aug 2008 09:39:51 +0100 (BST) Received: from [129.156.173.21] by fe-emea-10.sun.com (Sun Java System Messaging Server 6.2-8.04 (built Feb 28 2007)) with ESMTPSA id <0K5800GS42Q5CE90@fe-emea-10.sun.com>; Thu, 07 Aug 2008 09:39:42 +0100 (BST) Date: Thu, 07 Aug 2008 09:39:41 +0100 From: Darren J Moffat Subject: Re: EOF of Cache FileSystem (cachefs) [PSARC/2008/478 FastTrack timeout 08/04/2008] In-reply-to: <489872C1.1000308@sun.com> Sender: Darren.Moffat@sun.com To: Daniel Hain Cc: PSARC-ext@sun.com, "Nagakiran K.R" , Ebru Williams , cachefs-eof-discuss@sun.com Message-id: <489AB4CD.50404@Sun.COM> MIME-version: 1.0 Content-type: text/plain; format=flowed; charset=ISO-8859-1 Content-transfer-encoding: 7BIT X-PMX-Version: 5.4.1.325704 References: <488E141C.9060003@sun.com> <488E201D.1070004@sun.com> <488E29EB.5080803@Sun.COM> <488E2CB7.4020700@sun.com> <20080728221732.GA25547@Sun.COM> <488E4A8E.8090406@sun.com> <20080728225006.GE25547@Sun.COM> <488E5372.2070401@Egenera.COM> <488ed583.NWaDBV+/boGUWNyI%Joerg.Schilling@fokus.fraunhofer.de> <488E257B.90900@sun.com> <489240BB.5060809@sun.com> <4892CFF0.7060003@Sun.COM> <489872C1.1000308@sun.com> User-Agent: Thunderbird 2.0.0.14 (X11/20080630) Status: RO Content-Length: 1016 This derailed fast-track was voted on in PSARC on Wednesday 6th August 2008. There were no deny votes and a sufficient number of approve votes. An opinion will be produced purely for the purposes of advice to funding bodies. It will cover the following points (in more detail). Existing cachefs source/architecture needs to be EOF, committee happy with that. Existing cachefs was already lagging the current Solaris architecture since there is no support for NFSv4 or smbfs. CacheFS is still used by some large and important customers. Need a caching solution that can work with NFSv4, smbfs and possibly even filesystems accessed via FUSE (to be able to cache webdav of sshfs as examples). Advice to funding bodies to determine the business case and technical requirements for a replacement client cacheing system. The committee was happy that the project team could proceed with the rest of their EOF process requirements without waiting for the opinion to be produced. -- Darren J Moffat