Is it possible to emulate a unionfs with zfs and zones somehow? My zones are sparse zones and I want to make part of /usr writable within a zone. (/usr/perl5/mumble to be exact) I can''t just mount a writable directory on top of /usr/perl5 because then it hides all the stuff in the global zone. I could repopulate it in the local zone but ugh that is unattractive. I''m hoping for a better way. Creating a full zone is not an option for me. I don''t think this is possible but maybe someone else knows better. I was thinking something with snapshots and clones? -frank
Frank Cusack wrote:> Is it possible to emulate a unionfs with zfs and zones somehow? My zones > are sparse zones and I want to make part of /usr writable within a zone. > (/usr/perl5/mumble to be exact)Why don''t you just export that directory with NFS (rw) to your sparse zone and mount it on /usr/perl5/mumble ? Or is this too simple a thought? -- Dick Hoogendijk -- PGP/GnuPG key: F86289CE
Hi All, Anyone in the group using ZFS compression on clearcase vobs? If so any issues, gotchas? IBM support informs that ZFS compression is not supported. Any views on this? Rgds Roshan
On 04/02/2010 11:54, Roshan Perera wrote:> Anyone in the group using ZFS compression on clearcase vobs? If so any issues, gotchas?There shouldn''t be any issues and I''d be very surprised if there was.> IBM support informs that ZFS compression is not supported. Any views on this?Need more data on why the claim it isn''t supported - what issue have they seen or do they thing there could be. I see no reason that ZFS compression wouldn''t be supported, in fact Clearcase shouldn''t even be able to tell. Compression in ZFS is completely below the POSIX filesystem layer and completely out of the control of any application or even kernel service like NFS or CIFS that just uses POSIX interfaces. Same is true of deduplication and will be true of encryption when it integrates as well. -- Darren J Moffat
On Thu, Feb 4, 2010 at 2:09 AM, Frank Cusack <frank+lists/zfs at linetwo.net> wrote:> Is it possible to emulate a unionfs with zfs and zones somehow? ?My zones > are sparse zones and I want to make part of /usr writable within a zone. > (/usr/perl5/mumble to be exact) > > I can''t just mount a writable directory on top of /usr/perl5 because then > it hides all the stuff in the global zone. ?I could repopulate it in the > local zone but ugh that is unattractive. ?I''m hoping for a better way. > Creating a full zone is not an option for me. > > I don''t think this is possible but maybe someone else knows better. ?I > was thinking something with snapshots and clones?The way I normally do this is to (in the global zone) symlink /usr/perl5/mumble to somewhere that would be writable such as /opt, and then put what you need into that location in the zone. Leaves a dangling symlink in the global zone and other zones, but that''s relatively harmless. -- -Peter Tribble http://www.petertribble.co.uk/ - http://ptribble.blogspot.com/
Hi Darren, Thanks - IBM basically haven''t test clearcase with ZFS compression therefore, they don''t support currently. Future may change, as such my customer cannot use compression. I have asked IBM for roadmap info to find whether/when it will be supported. Thanks Roshan ----- Original Message ----- From: Darren J Moffat <darrenm at opensolaris.org> Date: Thursday, February 4, 2010 11:59 am Subject: Re: [zfs-discuss] ZFS compression on Clearcase To: Roshan Perera <Roshan.Perera at Sun.COM> Cc: zfs-discuss at opensolaris.org> On 04/02/2010 11:54, Roshan Perera wrote: > >Anyone in the group using ZFS compression on clearcase vobs? If so > any issues, gotchas? > > There shouldn''t be any issues and I''d be very surprised if there was. > > >IBM support informs that ZFS compression is not supported. Any views > on this? > > Need more data on why the claim it isn''t supported - what issue have > they seen or do they thing there could be. I see no reason that ZFS > compression wouldn''t be supported, in fact Clearcase shouldn''t even be > able to tell. > > Compression in ZFS is completely below the POSIX filesystem layer and > completely out of the control of any application or even kernel > service like NFS or CIFS that just uses POSIX interfaces. Same is > true of deduplication and will be true of encryption when it > integrates as well. > > -- > Darren J Moffat >
On 04.02.2010 12:12, dick hoogendijk wrote:> > Frank Cusack wrote: >> Is it possible to emulate a unionfs with zfs and zones somehow? My zones >> are sparse zones and I want to make part of /usr writable within a zone. >> (/usr/perl5/mumble to be exact) > > Why don''t you just export that directory with NFS (rw) to your sparse zone > and mount it on /usr/perl5/mumble ? Or is this too simple a thought? >What about lofs? I thinks lofs is the equivalent for unionfs on Solaris. E.g. mount -F lofs /originial/path /my/alternate/mount/point - Thomas
On 04/02/2010 12:13, Roshan Perera wrote:> Hi Darren, > > Thanks - IBM basically haven''t test clearcase with ZFS compression therefore, they don''t support currently. Future may change, as such my customer cannot use compression. I have asked IBM for roadmap info to find whether/when it will be supported.That is FUD generation in my opinion and being overly cautious. The whole point of the POSIX interfaces to a filesystem is that applications don''t actually care how the filesystem stores their data. UFS never had checksums before but ZFS adds those, but that didn''t mean that applications had to be checked because checksums were now done on the data. What if it was the disk drive that was doing the compression ? There would be similarly no way for the application to actually know that it is happening. What about every other feature we add to ZFS ? Like dedup (which is a type of compression) - again they app can''t tell. Or snapshots - the app can''t tell. Thats my opinion though and I know that ISVs can be very cautious about new features sometimes and overly so when it is far below their parts of the stack. Taking another example it would be like an ISV that supports their application running over NFS saying they don''t support a certain type of vendors switch in the network because they haven''t tested it. -- Darren J Moffat
Hi Darren, I totally agree with you and have raised some of the points mentioned but you have given even more items to pass on. I will update the alias when I hear further. Many Thanks Roshan ----- Original Message ----- From: Darren J Moffat <darrenm at opensolaris.org> Date: Thursday, February 4, 2010 12:42 pm Subject: Re: [zfs-discuss] ZFS compression on Clearcase To: Roshan Perera <Roshan.Perera at Sun.COM> Cc: zfs-discuss at opensolaris.org> On 04/02/2010 12:13, Roshan Perera wrote: > >Hi Darren, > > > >Thanks - IBM basically haven''t test clearcase with ZFS compression > therefore, they don''t support currently. Future may change, as such my > customer cannot use compression. I have asked IBM for roadmap info to > find whether/when it will be supported. > > That is FUD generation in my opinion and being overly cautious. The > whole point of the POSIX interfaces to a filesystem is that > applications don''t actually care how the filesystem stores their data. > > UFS never had checksums before but ZFS adds those, but that didn''t > mean that applications had to be checked because checksums were now > done on the data. > > What if it was the disk drive that was doing the compression ? There > would be similarly no way for the application to actually know that it > is happening. > > What about every other feature we add to ZFS ? Like dedup (which is > a type of compression) - again they app can''t tell. Or snapshots - > the app can''t tell. > > Thats my opinion though and I know that ISVs can be very cautious > about new features sometimes and overly so when it is far below their > parts of the stack. > > Taking another example it would be like an ISV that supports their > application running over NFS saying they don''t support a certain type > of vendors switch in the network because they haven''t tested it. > > -- > Darren J Moffat >
On Thu, 4 Feb 2010, Darren J Moffat wrote:>> >> Thanks - IBM basically haven''t test clearcase with ZFS compression >> therefore, they don''t support currently. Future may change, as such my >> customer cannot use compression. I have asked IBM for roadmap info to find >> whether/when it will be supported. > > That is FUD generation in my opinion and being overly cautious. The whole > point of the POSIX interfaces to a filesystem is that applications don''t > actually care how the filesystem stores their data.Clearcase itself implements a versioning filesystem so perhaps it is not being overly cautious. Compression could change aspects such as how free space is reported. As I recall, Clearcase maintains a database (on top of a filesystem) on a central server to store the actual data. When a user checks out a view of the files, the user views the files via a versioning filesystem, which stores a cache of those file on the local system. Clearcase intruments access to its versioning filesystem so it knows all of the actions which resulted in a built object. This means that there are two places (server and client) where zfs may be involved. Bob -- Bob Friesenhahn bfriesen at simple.dallas.tx.us, http://www.simplesystems.org/users/bfriesen/ GraphicsMagick Maintainer, http://www.GraphicsMagick.org/
On 04/02/2010 12:42, Darren J Moffat wrote:> On 04/02/2010 12:13, Roshan Perera wrote: >> Hi Darren, >> >> Thanks - IBM basically haven''t test clearcase with ZFS compression >> therefore, they don''t support currently. Future may change, as such >> my customer cannot use compression. I have asked IBM for roadmap info >> to find whether/when it will be supported. > > That is FUD generation in my opinion and being overly cautious. The > whole point of the POSIX interfaces to a filesystem is that > applications don''t actually care how the filesystem stores their data. >I agree (*). It is very similar to what EMC did some years ago by officially stating that while ZFS is supported on their disk arrays ZFS snapshots are not. Even more "funny". (*) - however compression is not entirely transparent in such a sense that a reported disk space usage might not be exactly what application expects. But I''m not saying it is an issue here - I honestly don''t know. -- Robert Milkowski http://milek.blogspot.com
On 4 Feb 2010, at 16:35, Bob Friesenhahn wrote:> On Thu, 4 Feb 2010, Darren J Moffat wrote: >>> Thanks - IBM basically haven''t test clearcase with ZFS compression therefore, they don''t support currently. Future may change, as such my customer cannot use compression. I have asked IBM for roadmap info to find whether/when it will be supported. >> >> That is FUD generation in my opinion and being overly cautious. The whole point of the POSIX interfaces to a filesystem is that applications don''t actually care how the filesystem stores their data. > > Clearcase itself implements a versioning filesystem so perhaps it is not being overly cautious. Compression could change aspects such as how free space is reported.I''d also like to echo Bob''s observations here. Darren''s FUDFUD is based on limited experience of ClearCase, I expect ... On the client side, ClearCase actually presnets itself as a mounted filesystem, regardless of what the OS has under the covers. In other words, a ClearCase directory will never be ''ZFS'' because it''s not ZFS, it''s ClearCaseFS. On the server side (which might be the case here) the way ClearCase works is to represent the files and contents in a way more akin to a database (e.g. Oracle) than traditional file-system approaches to data (e.g. CVS, SVN). In much the same way there are app-specific issues with ZFS (e.g. matching block-sizes, dealing with ZFS snapshots on a VM image and so forth) there may well be some with ClearCase. At the very least, though, IBM may just be unable/willing to test it at the time and put their stamp of approval on it. In many cases for IBM products, there are supported platforms (often with specific patch levels), much like there are offically supported Solaris platforms and hot-fixes to go for certain applications. They may well just being cautious in what there is until they''ve had time to test it out for themselves - or more likely, until the first set of paying customers wants to get invoiced for the investigation. But to claim it''s FUD without any real data to back it up is just FUD^2. Alex
On February 4, 2010 12:12:04 PM +0100 dick hoogendijk <dick at nagual.nl> wrote:> Why don''t you just export that directory with NFS (rw) to your sparse zone > and mount it on /usr/perl5/mumble ? Or is this too simple a thought?On February 4, 2010 1:41:20 PM +0100 Thomas Maier-Komor <thomas at maier-komor.de> wrote:> What about lofs? I thinks lofs is the equivalent for unionfs on Solaris.The problem with both of those solutions is a) writes will overwrite the original filesystem data and b) writes will be visible to everyone else. Neither suggestion provides unionfs capability. On February 4, 2010 12:12:18 PM +0000 Peter Tribble <peter.tribble at gmail.com> wrote:> The way I normally do this is to (in the global zone) symlink > /usr/perl5/mumble to somewhere that would be writable such as /opt, and > then put what you need into that location in the zone. Leaves a dangling > symlink in the global zone and other zones, but that''s relatively > harmless.The problem with that is you don''t see the underlying data that exists in the global zone. I do use that technique for other data (e.g. the entire /usr/local hierarchy), but it doesn''t meet my desired needs in this case. I looked into clones (and at least now I understand them much better than before) and they *almost* provide the functionality I want. I could mount a clone in the zoned version of /foo and it would see the original /foo, and changes would go to the clone only, just like a real unionfs. What it''s lacking though is that when the underlying filesystem changes (in the global zone), those changes don''t percolate up to the clone. The clone''s base view of files is from the snapshot it was generated from, which cannot change. It would be great if you could re-target (or re-base?) a clone from a different snapshot than the one it was originally generated from. Since I don''t need realtime updates, for my purposes that would be a great equivalent to a true unionfs. So the thread on zfs diff gave me an idea; I will use clones and will write a ''zfs diff''-like tool. When the original /usr/perl5/mumble changes I will use that to pick out files that are different in the clone and populate a new clone with them. -frank
BTW, I could just install everything in the global zone and use the default "inheritance" of /usr into each local zone to see the data. But then my zones are not independent portable entities; they would depend on some non-default software installed in the global zone. Just wanted to explain why this is valuable to me and not just some crazy way to do something simple. -frank
On Thu, Feb 04, 2010 at 03:19:15PM -0500, Frank Cusack wrote:> BTW, I could just install everything in the global zone and use the > default "inheritance" of /usr into each local zone to see the data. > But then my zones are not independent portable entities; they would > depend on some non-default software installed in the global zone. > > Just wanted to explain why this is valuable to me and not just some > crazy way to do something simple.There''s no unionfs for Solaris. (For those of you who don''t know, unionfs is a BSDism and is a pseudo-filesystem which presents the union of two underlying filesystems, but with all changes being made only to one of the two filesystems. The idea is that one of the underlying filesystems cannot be modified through the union, with all changes made through the union being recorded in an overlay fs. Think, for example, of unionfs- mounting read-only media containing sources: you could cd to the mount point and build the sources, with all intermediate files and results placed in the overlay.) In Frank''s case, IIUC, the better solution is to avoid the need for unionfs in the first place by not placing pkg content in directories that one might want to be writable from zones. If there''s anything about Perl5 (or anything else) that causes this need to arise, then I suggest filing a bug. Nico --
On 2/4/10 2:46 PM -0600 Nicolas Williams wrote:> In Frank''s case, IIUC, the better solution is to avoid the need for > unionfs in the first place by not placing pkg content in directories > that one might want to be writable from zones. If there''s anything > about Perl5 (or anything else) that causes this need to arise, then I > suggest filing a bug.Right, and thanks for chiming in. Problem is that perl wants to install add-on packages in places that the coincide with the system install. Most stuff is limited to the site_perl directory, which is easily redirected, but it also has some other locations it likes to meddle with. -frank
On Thu, Feb 04, 2010 at 04:03:19PM -0500, Frank Cusack wrote:> On 2/4/10 2:46 PM -0600 Nicolas Williams wrote: > >In Frank''s case, IIUC, the better solution is to avoid the need for > >unionfs in the first place by not placing pkg content in directories > >that one might want to be writable from zones. If there''s anything > >about Perl5 (or anything else) that causes this need to arise, then I > >suggest filing a bug. > > Right, and thanks for chiming in. Problem is that perl wants to install > add-on packages in places that the coincide with the system install. > Most stuff is limited to the site_perl directory, which is easily > redirected, but it also has some other locations it likes to meddle with.Maybe we need a zone_perl location. Judicious use of the search paths will get you out of this bind, I think. Nico --
> On 4 Feb 2010, at 16:35, Bob Friesenhahn wrote: > >> > On Thu, 4 Feb 2010, Darren J Moffat wrote: >>>> >>> Thanks - IBM basically haven''t test clearcase with ZFS compression therefore, they don''t support currently. Future may change, as such my customer cannot use compression. I have asked IBM for roadmap info to find whether/when it will be supported. >>> >> >>> >> That is FUD generation in my opinion and being overly cautious. The whole point of the POSIX interfaces to a filesystem is that applications don''t actually care how the filesystem stores their data. >> > >> > Clearcase itself implements a versioning filesystem so perhaps it is not being overly cautious. Compression could change aspects such as how free space is reported. > I''d also like to echo Bob''s observations here. Darren''s FUDFUD is> based on limited experience of ClearCase, I expect ... I do know how ClearCase works and it works *above* the POSIX layer in ZFS - at the VFS layer (and higher). [I''ve debugged Solaris crash dumps with the clear case kernel modules loaded in them in the past]. By FUD I don''t mean it is wrong, but without information about a bug or observed undesirable behaviour it is coming across as Fear that there could be problems. Basically we need more data. What I was pointing out is that because of the layer that ClearCase works there should be no problems - I''m not saying there aren''t any just that I don''t see where they would be. If there are problems with ZFS then bugs should be logged, leaving statements like "ISV x doesn''t support using feature f of ZFS" is harm full to the ISV''s product and to ZFS when there is no bug logged or data about why there is a problem. -- Darren J Moffat
Nicolas Williams <Nicolas.Williams at sun.com> wrote:> There''s no unionfs for Solaris. > > (For those of you who don''t know, unionfs is a BSDism and is a > pseudo-filesystem which presents the union of two underlying > filesystems, but with all changes being made only to one of the two > filesystems. The idea is that one of the underlying filesystems cannot > be modified through the union, with all changes made through the union...and it seems that the ideas for this FS have been taken from TFS (Translucent file system) that appeared in Sun OS in 1986 already. J?rg -- EMail:joerg at schily.isdn.cs.tu-berlin.de (home) J?rg Schilling D-13353 Berlin js at cs.tu-berlin.de (uni) joerg.schilling at fokus.fraunhofer.de (work) Blog: http://schily.blogspot.com/ URL: http://cdrecord.berlios.de/private/ ftp://ftp.berlios.de/pub/schily