Re: [zfs-discuss] ZFS file system confusion
Chris Dunbar wrote: Let's say I create the ZFS file system tank/nfs and share that over NFS. Then I create the ZFS file systems tank/nfs/foo1 and tank/nfs/foo2. I want to manage snapshots independently for foo1 and foo2, but I would like to be able to access both from the single NFS share for tank/nfs. Here are my questions: 1. Can I in fact access foo1 and foo2 through the NFS share of tank/nfs or do I need to create separate NFS shares for each of them? They will be separate shares, but you should be able to avoid having to touch this with ZFS inheritance, as long as the subshares should all be shared the same way as the parent. 2. Is there any difference in interacting with foo1 and foo2 through the tank/nfs share versus interacting with them directly? I don't even know if that question makes sense, but it's at the heart of my confusion - nesting file systems. Since they're separate-but-related shares, the client needs code to detect and handle mounting of the subshares, ideally without the client user do anything. If you are using modern Nevada or OpenSolaris, this is done, but Solaris 10 does not do it. 3. If I make a snapshot of tank/nfs, does it include the data in foo1 and foo2 or are they excluded since they are separate ZFS file systems? They're separate, but zfs snapshot -r will do them all at once. Rob T ___ zfs-discuss mailing list zfs-discuss@opensolaris.org http://mail.opensolaris.org/mailman/listinfo/zfs-discuss
Re: [zfs-discuss] ZFS file system confusion
Brandon High wrote: If you mount server:/nfs on another host, it will not include server:/nfs/foo1 or server:/nfs/foo2. Some nfs clients (notably Solaris's) will attempt to mount the foo1 foo2 datasets automatically, so it looks like you've exported everything under server:/nfs. Linux clients don't behave in the same fashion, you'll have to separately mount all the exports. Hi Brendan, I believe this is incorrect - Solaris Nevada has supported this automatic subshare mounting (we call it mirror mounts) since build 77, but it's not in Solaris 10, while I believe Linux has had it for a longer time. Is this not what you see on current Linux? Rob T ___ zfs-discuss mailing list zfs-discuss@opensolaris.org http://mail.opensolaris.org/mailman/listinfo/zfs-discuss
Re: [zfs-discuss] ZFS file system confusion
Stefan Walk wrote: On debian linux (lenny), the nfs4 client automatically mounts subshares, but the nfs3 client doesn't (May not be right in all cases, just my experience). NFSv3 has no way to do this in the protocol, so this is as designed (and the same as current Solaris/OpenSolaris). Rob T ___ zfs-discuss mailing list zfs-discuss@opensolaris.org http://mail.opensolaris.org/mailman/listinfo/zfs-discuss
Re: [zfs-discuss] ZFS file system confusion
Damon Atkins wrote: NFSv4 has a concept of a root of the overall exported filesystem (Pseudofilesystem). FileHandle 0 in terms of Linux it is setting fsid=0 when exporting. Which would explain why someone said Linux (NFSv4) automounts an exported filesystem under another exported filesystem ie mount servername:/ and be able to browes all exported/shared file systems you have access to. I don't think this made it into Solaris NFSv4 server. Correct, we believe the client should do the work here, not the server. The tough problem with letting the server pretend all subshares are part of one big filesystem is that there can be fileid/inode number collisions between objects in separate underlying filesystems, and Posix applications can do bad things in those cases. There's no graceful way to do this in NFSv2/v3, but v4 solves it. Rob T ___ zfs-discuss mailing list zfs-discuss@opensolaris.org http://mail.opensolaris.org/mailman/listinfo/zfs-discuss
Re: [zfs-discuss] sharenfs option rw,root=host1 don't take effect
Ian Collins wrote: On 03/11/10 05:42 AM, Andrew Daugherity wrote: I've found that when using hostnames in the sharenfs line, I had to use the FQDN; the short hostname did not work, even though both client and server were in the same DNS domain and that domain is in the search path, and nsswitch uses DNS for hosts (read: 'ping client1' works fine, as does 'mount server:/export/fs /mnt' from client1). I have found the same, whether sharing to Linux or Solaris hosts, the FQDN appears to be required. It's not quite true that you need the FQDN, as it still does depend on the name service setup. However, what is true is this: to authenticate a client, the server does a IP-to-hostname mapping and compares the string with the string on the share entry. If the strings match (ignoring case), the client gets access. If not, the client does not get access. This has confused many, and it's not clear how or where to document this so that it does not cause more confusion. RFEs with example language would be welcome. So, to make a long story short, if you log into the server from the client and do who am i, you will get the host name you need for the share. Rob T ___ zfs-discuss mailing list zfs-discuss@opensolaris.org http://mail.opensolaris.org/mailman/listinfo/zfs-discuss
Re: [zfs-discuss] nfs mounts don't follow child filesystems?
Frank Cusack wrote: I thought with NFS4 *on solaris* that clients would follow the zfs filesystem hierarchy and mount sub-filesystems. That doesn't seem to be happening and I can't find any documentation on it (either way). Did I only dream up this feature or does it actually exist? I am using s10_u8. Hi Frank, Solaris Nevada does this in build 77 or later, but it has not been backported to a Solaris 10 update. Rob T ___ zfs-discuss mailing list zfs-discuss@opensolaris.org http://mail.opensolaris.org/mailman/listinfo/zfs-discuss
Re: [zfs-discuss] zfs inotify?
Andrew Daugherity wrote: if I invoke bart via truss, I see it calls statvfs() and fails. Way to keep up with the times, Sun! % file /bin/truss /bin/amd64/truss /bin/truss: ELF 32-bit LSB executable 80386 Version 1 [FPU], dynamically linked, not stripped, no debugging information available /bin/amd64/truss: ELF 64-bit LSB executable AMD64 Version 1 [SSE2 SSE FXSR CMOV FPU], dynamically linked, not stripped, no debugging information available Rob T ___ zfs-discuss mailing list zfs-discuss@opensolaris.org http://mail.opensolaris.org/mailman/listinfo/zfs-discuss
Re: [zfs-discuss] Desire simple but complete copy - How?
David Dyer-Bennet wrote: And I haven't been able to make incremental replication send/receive work. Supposed to be working on that, but now I'm having trouble getting a VirtualBox install that works (my real NAS is physical, but I'm using virtual systems to test things). I've had good success practicing and debugging zfs stuff by creating small pools based on files and tinkering with those, e.g. # mkfile 100m /root/zpool_test1 # zpool create test1 /root/zpool_test1 # mkfile 100m /root/zpool_test2 # zpool create test2 /root/zpool_test2 This can get you a source of non-production data on a real server. Rob T ___ zfs-discuss mailing list zfs-discuss@opensolaris.org http://mail.opensolaris.org/mailman/listinfo/zfs-discuss
Re: [zfs-discuss] [osol-discuss] Which kind of ACLs does tmpfs support ?
Roland Mainz wrote: Ok... does that mean that I have to create a ZFS filesystem to actually test ([1]) an application which modifies ZFS/NFSv4 ACLs or are there any other options ? By all means, test with ZFS. But it's easy to do that: # mkfile 64m /zpool.file # zpool create test /zpool.file # zfs list test 67.5K 27.4M18K /test Rob T ___ zfs-discuss mailing list zfs-discuss@opensolaris.org http://mail.opensolaris.org/mailman/listinfo/zfs-discuss
Re: [zfs-discuss] Not sure how to do this in zfs
Gregory Skelton wrote: Yes, that is exactly whats happening to us. I've tried to share the zfs inside the other zfs. Like so, but I'm still seeing an empty directory. What are you using for a client? What version of NFS? NFSv4 in Solaris Nevada build 77 and later, or any OpenSolaris versions, will do this mirror mounts stuff automatically. Other than that, it's manual mounts or automounter map entries. Rob T ___ zfs-discuss mailing list zfs-discuss@opensolaris.org http://mail.opensolaris.org/mailman/listinfo/zfs-discuss
Re: [zfs-discuss] Not sure how to do this in zfs
Gregory Skelton wrote: What are you using for a client? What version of NFS? We're using Red Hat Enterprise Linux(Centos) 5.3 for the clients, with nfs 3 You should try NFSv4 - Linux NFSv4 support came in with this mirror mount support. If its possible, I'd still like to mount the base dir, and get the sub directories (other zfs's) access for free. Some other OSs have code to make their servers pretend nested mounts are part of the same big filesystem, but we don't like the issues that that causes, and won't add such support to the Solaris server. Rob T ___ zfs-discuss mailing list zfs-discuss@opensolaris.org http://mail.opensolaris.org/mailman/listinfo/zfs-discuss
Re: [zfs-discuss] [indiana-discuss] zfs issues?
James Lever wrote: I had help trying to create a crash dump, but everything we tried didn't cause the system to panic. 0eip;:c;:c and other weird magic I don't fully grok I can't help with your ZFS issue, but to get a reasonable crash dump in circumstances like these, you should be able to do savecore -L on OpenSolaris. Rob T ___ zfs-discuss mailing list zfs-discuss@opensolaris.org http://mail.opensolaris.org/mailman/listinfo/zfs-discuss
Re: [zfs-discuss] getting actual size in bytes of a zfs fs
Harry Putnam wrote: I think this has probably been discussed here.. but I'm getting confused about how to determine actual disk usage of zfs filesystems. Here is an example: $ du -sb callisto 46744 callisto $ du -sb callisto/.zfs/snapshot 86076 callisto/.zfs/snapshot Two questions then. I do need to add those two to get the actual disk usage right? Is something wrong here... there are only 2 snapshots there. And I've seen it mentioned repeatedly about how little space snapshots take. 'du' does a stat() of each file it finds; it sees and reports identical files in snapshots as full size. 'rsync' will also work on all copies of a file. To see space usage, you need to ask zfs itself: NAMEUSED AVAIL REFER MOUNTPOINT rpool/ROOT 10.4G 7.93G18K /rpool/ROOT rpool/r...@rob 0 -18K - The snapshot I just took and named after myself doesn't yet take any space for itself. If I delete a file, e.g. my /var/crash/* files that I'm done with, I *may* see space start to be accounted to the snapshot. Rob T ___ zfs-discuss mailing list zfs-discuss@opensolaris.org http://mail.opensolaris.org/mailman/listinfo/zfs-discuss
Re: [zfs-discuss] [on-discuss] Reliability at power failure?
dick hoogendijk wrote: Sorry Uwe, but the answer is yes. Assuming that your hardware is in order. I've read quite some msgs from you here recently and all of them make me think you're no fan of zfs at all. Why don't you quit using it and focus a little more on installing SunStudio I would really like to NOT chase people away from ZFS for any reason. There's no need. ZFS is currently a little too expert-friendly. I'm used to ZFS, so when it shows me messages, I know what it's saying. But when I read them a second time, I always wonder if we could word them to be more approachable without losing the precision. I would like to see alternate wordings suggested in RFEs, since I think some folks had good suggestions. As an example of wording that needs an upgrade: errors: Permanent errors have been detected in the following files: 0xa6:0x4f002 Could we not offer a clue that this was in metadata, even if it is darned hard to print a meaningful path name? Obligatory positive message: I was rewiring my monitors yesterday to get them all on a switchable power bar, and bumped a power switch briefly. The old dual Opteron machine hosting my storage pool did not power up again after that. I had an external Firewire case the pool had been destined for, and so I removed the drives and put them in the external case, and plugged the case into my SunBlade 2500. 'zpool import -f' went nicely, and I didn't lose a thing. I don't think any other filesystem or OS would make a recovery operation like this any easier. Oh yeah, this was after a mostly-effortless ZFS-accelerated Live Upgrade from snv_91 to snv_112 (almost a year) on another box. Rob T ___ zfs-discuss mailing list zfs-discuss@opensolaris.org http://mail.opensolaris.org/mailman/listinfo/zfs-discuss
Re: [zfs-discuss] Can this be done?
Michael Shadle wrote: I'm going to try to move one of my disks off my rpool tomorrow (since it's a mirror) to a different controller. According to what I've heard before, ZFS should automagically recognize this new location and have no problem, right? Or do I need to do some sort of detach/etc. process first? I've got a 4-way RaidZ pool made from IDE disks that I've connected in three different ways: - via a Firewire-to-IDE case - via a 4-port PCI-to-IDE card - via 4 SATA-to-IDE converters Each transition resulted in different device IDs, but I could always see them with 'zpool import'. You should 'zpool export' your pool first. Rob T ___ zfs-discuss mailing list zfs-discuss@opensolaris.org http://mail.opensolaris.org/mailman/listinfo/zfs-discuss
Re: [zfs-discuss] Confused about prerequisites for ZFS to work
Harry Putnam wrote: There is a comment in those directions about installing a SMB PAM module: 6. Install the SMB PAM module Add the below line to the end of /etc/pam.conf: other password required pam_smb_passwd.so.1 nowarn Do you know what that is? It's part of the Solaris CIFS server, and its purpose is to permit you to store passwords in a form useful to CIFS. The regular passwords are stored with one-way encryption, and CIFS needs the plain text to encrypt a different way for interoperability. The PAM module sees the password as it is changed, and will store it for CIFS purposes. Rob T ___ zfs-discuss mailing list zfs-discuss@opensolaris.org http://mail.opensolaris.org/mailman/listinfo/zfs-discuss
Re: [zfs-discuss] ZFS Sharing over smb - permissions/access
Aaron wrote: I have setup a fileserver using zfs and am able to see the share from my mac. I am able to create/write to the share as well as read. I've ensured that I have the same user and uid on both the server (opensolaris snv101b) as well as the mac. The root folder of the share is owned by root:mygroup. When I write/create new files on the share, they get created, but the permissions are such: -- 1 aaron staff14453522 2009-01-03 15:41 myFile.txt aaron:staff is the user on the mac (leopard). When I mounted the share, I used aaron as the user. What I really would like is for this share to have newly written/created files be owned by root:mygroup. This is a limitation on the part of the Mac 'smbfs' client. We use the same code base on Solaris. The code is not currently able to do I/O on the part of multiple users; the user who was authenticated at mount time owns all of the files. Also, the Mac client does not try to parse ACLs at all, so permission mode bits and reported ownership are guesses done at the client. If you set ACLs on the server, they should be enforced, even if you can't see that from the Mac. If the ownership or perm bits are in your way on the Mac, you can use smbfs mount options to get it to tell you different things, but there's no way to see the truth until more code is written. Rob T ___ zfs-discuss mailing list zfs-discuss@opensolaris.org http://mail.opensolaris.org/mailman/listinfo/zfs-discuss
Re: [zfs-discuss] ZFS Sharing over smb - permissions/access
Aaron wrote: Ok, thanks for the info - I was really puling my hair out over this. Would you know if sharing over nfs via zfs would fare any better? I am *quite* happy with the Mac NFS client, and use it against ZFS files all the time. It's worth the time to make sure you're using the same numeric UIDs on both the client and server if you're using the default authentication settings. Rob T ___ zfs-discuss mailing list zfs-discuss@opensolaris.org http://mail.opensolaris.org/mailman/listinfo/zfs-discuss
Re: [zfs-discuss] firewire card?
Frank Cusack wrote: just installed s10_u6 with a root pool. i'm blown away. so now i want to attach my external storage via firewire. I was able to use this cheap thing with good initial results: http://www.newegg.com/Product/Product.aspx?Item=N82E16815124002 However, I ran into a frequent hang[1] and declined to put it in the HWCL. The hang appears to be a bug in the scsa1394 kernel module, and are not yet fixed. I've moved the disks our of their Firewire case and inside a machine with SATA-to-IDE converters (ick). [1] http://bugs.opensolaris.org/view_bug.do?bug_id=6539587 Rob T ___ zfs-discuss mailing list zfs-discuss@opensolaris.org http://mail.opensolaris.org/mailman/listinfo/zfs-discuss
Re: [zfs-discuss] zfs import/export sym-link unlike endianness?
Mark Wiederspahn wrote: I'm exporting/importing a zpool from a sun 4200 running Solaris 10 10/08 s10x_u6wos_07b X86 to a t2000 running Solaris 10 10/08 s10s_u6wos_07b SPARC. Neither one is yet patched, but I didn't see anything obvious on sunsolve for recent updates. The filesysem contains symbolic links. I made a copy to a new zpool of an nfs-mounted filesystem with find and cpio, and I used rsync to verify the tree against the original, then did an export and import on the sparc, and tried the same rsync. I found a bunch (all?)of sym-links were different. An example: On x64 system: ls -l spare/geoframe/iesx/scratch/queue lrwxrwxrwx 1 root other 30 Dec 18 19:21 spare/geoframe/iesx/scratch/queue - /disk/plots/CGM+TGF_files_here On sparc system: ls -l spare/geoframe/iesx/scratch/queue lrwxrwxrwx 1 root other 30 Dec 18 19:21 spare/geoframe/iesx/scratch/queue - lp/ksid/ots/CGM+TGF_files_here Note the mangled target. Importing back into the x64 system rsync's fine. This looks like known bug 6764193, Broken symlinks on cross platform zfs send/recv - the public comments state that export/import shows the problem. It's fixed in Nevada build 105, but not in a Solaris 10 update so far. Rob T ___ zfs-discuss mailing list zfs-discuss@opensolaris.org http://mail.opensolaris.org/mailman/listinfo/zfs-discuss
Re: [zfs-discuss] Quantifying ZFS reliability
Miles Nordin wrote: sounds like they are not good enough though, because unless this broken router that Robert and Darren saw was doing NAT, yeah, it should not have touch the TCP/UDP checksum. I believe we proved that the problem bit flips were such that the TCP checksum was the same, so the original checksum still appeared correct. BTW which router was it, or you can't say because you're in the US? :) I can't remember; it was aging at the time. Rob T ___ zfs-discuss mailing list zfs-discuss@opensolaris.org http://mail.opensolaris.org/mailman/listinfo/zfs-discuss
Re: [zfs-discuss] Quantifying ZFS reliability
Ahmed Kamal wrote: BTW, for everyone saying zfs is more reliable because it's closer to the application than a netapp, well at least in my case it isn't. The solaris box will be NFS sharing and the apps will be running on remote Linux boxes. So, I guess this makes them equal. How about a new reliable NFS protocol, that computes the hashes on the client side, sends it over the wire to be written remotely on the zfs storage node ?! We've actually prototyped an NFS protocol extension that does this, but the challenges are integrating it with ZFS to form a single protection domain, and getting the protocol to be a standard. For now, an option you have is Kerberos with data integrity; the sender computes a CRC of the data and the receiver can verify it to rule out OTW corruption. This is, of course, not end-to-end from platter to memory, but introduces a separate protection domain for the NFS link. Rob T ___ zfs-discuss mailing list zfs-discuss@opensolaris.org http://mail.opensolaris.org/mailman/listinfo/zfs-discuss
Re: [zfs-discuss] Quantifying ZFS reliability
Bob Friesenhahn wrote: On Wed, 1 Oct 2008, Ahmed Kamal wrote: So, I guess this makes them equal. How about a new reliable NFS protocol, that computes the hashes on the client side, sends it over the wire to be written remotely on the zfs storage node ?! Modern NFS runs over a TCP connection, which includes its own data validation. This surely helps. Less than we'd sometimes like :-) The TCP checksum isn't very strong, and we've seen corruption tied to a broken router, where the Ethernet checksum was recomputed on bad data, and the TCP checksum didn't help. It sucked. Rob T ___ zfs-discuss mailing list zfs-discuss@opensolaris.org http://mail.opensolaris.org/mailman/listinfo/zfs-discuss
Re: [zfs-discuss] Quantifying ZFS reliability
Miles Nordin wrote: There are checksums in the ethernet FCS, checksums in IP headers, checksums in UDP headers (which are sometimes ignored), and checksums in TCP (which are not ignored). There might be an RPC layer checksum, too, not sure. Different arguments can be made against each, I suppose, but did you have a particular argument in mind? Have you experienced corruption with NFS that you can blame on the network, not the CPU/memory/busses of the server and client? Absolutely. See my recent post in this thread. The TCP checksum is not that strong, and a router broken the right way can regenerate a correct-looking Ethernet checksum on bad data. krb5i fixed it nicely. Rob T ___ zfs-discuss mailing list zfs-discuss@opensolaris.org http://mail.opensolaris.org/mailman/listinfo/zfs-discuss
Re: [zfs-discuss] zfs/nfs issue editing existing files
Brandon High wrote: On Mon, Jun 9, 2008 at 3:14 PM, Andy Lubel [EMAIL PROTECTED] wrote: Tried this today and although things appear to function correctly, the performance seems to be steadily degrading. Am I getting burnt by double-caching? If so, what is the best way to workaround for my sad situation? I tried directio for the ufs volume and it made it even worse.. AFAIK, you're doing the best that you can while playing in the constraints of ZFS. If you want to use nfs v3 with your clients, you'll need to use UFS as the back end. Just a clarification: NFSv3 isn't a problem to my knowledge in general; Andy has a problem with a HP-UX client bug that he can't appear to get a fix for. Rob T ___ zfs-discuss mailing list zfs-discuss@opensolaris.org http://mail.opensolaris.org/mailman/listinfo/zfs-discuss
Re: [zfs-discuss] zfs/nfs issue editing existing files
Andy Lubel wrote: I've got a real doozie.. We recently implemented a b89 as zfs/nfs/ cifs server. The NFS client is HP-UX (11.23). What's happening is when our dba edits a file on the nfs mount with vi, it will not save. I removed vi from the mix by doing 'touch /nfs/file1' then 'echo abc /nfs/file1' and it just sat there while the nfs servers cpu went up to 50% (one full core). Hi Andy, This sounds familiar: you may be hitting something I diagnosed last year. Run snoop and see if it loops like this: 10920 0.00013 141.240.193.235 - 141.240.193.27 NFS C GETATTR3 FH=6614 10921 0.7 141.240.193.27 - 141.240.193.235 NFS R GETATTR3 OK 10922 0.00017 141.240.193.235 - 141.240.193.27 NFS C SETATTR3 FH=6614 10923 0.7 141.240.193.27 - 141.240.193.235 NFS R SETATTR3 Update synch mismatch 10924 0.00017 141.240.193.235 - 141.240.193.27 NFS C GETATTR3 FH=6614 10925 0.00023 141.240.193.27 - 141.240.193.235 NFS R GETATTR3 OK 10926 0.00026 141.240.193.235 - 141.240.193.27 NFS C SETATTR3 FH=6614 10927 0.9 141.240.193.27 - 141.240.193.235 NFS R SETATTR3 Update synch mismatch If you see this, you've hit what we filed as Sun bugid 6538387, HP-UX automount NFS client hangs for ZFS filesystems. It's an HP-UX bug, fixed in HP-UX 11.31. The synopsis is that HP-UX gets bitten by the nanosecond resolution on ZFS. Part of the CREATE handshake is for the server to send the create time as a 'guard' against almost-simultaneous creates - the client has to send it back in the SETATTR to complete the file creation. HP-UX has only microsecond resolution in their VFS, and so the 'guard' value is not sent accurately and the server rejects it, lather rinse and repeat. The spec, RFC 1813, talks about this in section 3.3.2. You can use NFSv2 in the short term until you get that update. If you see something different, by all means send us a snoop. Rob T ___ zfs-discuss mailing list zfs-discuss@opensolaris.org http://mail.opensolaris.org/mailman/listinfo/zfs-discuss
Re: [zfs-discuss] Per-user home filesystems and OS-X Leopard anomaly
Bob Friesenhahn wrote: I can't speak from a Mac-centric view, but for my purposes NFS in Leopard works well. The automounter in Leopard is a perfect clone of the Solaris automounter, and may be based on OpenSolaris code. It is based on osol code. The implementor worked a long time at Sun :-) Rob T ___ zfs-discuss mailing list zfs-discuss@opensolaris.org http://mail.opensolaris.org/mailman/listinfo/zfs-discuss
Re: [zfs-discuss] Trial x4500, zfs with NFS and quotas.
Jorgen Lundman wrote: SXCE is coming out _very_ soon. But all of your clients need to support NFSv4 mount point crossing to make full use of it, unless the automounter works out well enough. Ahh, that's a shame.. Automounter works sufficiently at the moment, but it does not work well with discovering new file-systems. Yes, that's something I fight with, as well. We tried to make the mount point crossing support better here. I made the mistake of umount -f /net/x4500/export/mail, even when autofs was disabled, and now all I get is I/O Errors. Is it always this sensitive? umount -f is a power tool with no guard. If you had local apps using the filesystem, they would have seen I/O errors as well. The automounter is not making things worse here, so calling it sensitive doesn't sound right to me. Rob T ___ zfs-discuss mailing list zfs-discuss@opensolaris.org http://mail.opensolaris.org/mailman/listinfo/zfs-discuss
Re: [zfs-discuss] Trial x4500, zfs with NFS and quotas.
[EMAIL PROTECTED] wrote: I made the mistake of umount -f /net/x4500/export/mail, even when autofs was disabled, and now all I get is I/O Errors. Is it always this sensitive? umount -f is a power tool with no guard. If you had local apps using the filesystem, they would have seen I/O errors as well. The automounter is not making things worse here, so calling it sensitive doesn't sound right to me. The biggest issue, though, here is that the automounter's /net mounts for each host are read only once when the mountpoint is first established. It's only ever refreshed when all the host's filesystems are unmounted. Yes, and what's worse is that that can't be done manually in a reasonable way - the unmounts just fail unless they're driven by the unmount thread. I'd love to get this fixed sometime ... Rob T ___ zfs-discuss mailing list zfs-discuss@opensolaris.org http://mail.opensolaris.org/mailman/listinfo/zfs-discuss
Re: [zfs-discuss] Trial x4500, zfs with NFS and quotas.
Jorgen Lundman wrote: *** NFS Option Start: Since we need quota per user, I need to create a file-system of size=$quota for each user. But NFS will not let you cross mount-point/file-systems so mounting just /export/mail/ means I will not see any directory below that. NFSv4 will let the client cross mount points transparently; this is implemented in Nevada build 77, and in Linux and AIX. On the NFS client side, this would mean I would have to do 194172 NFS mounts to see my file-system. Can normal Unix servers even do this? If they all had to be mounted at the same time, I'd expect issues, but an automounter is a better idea if you need to support clients other than listed above. From Googling, it seems suggested that I use automount, which would cut out any version of Unix without automount, either from the age of the OS (early Sun might be ok still?) and Unix flavours without automount. As another poster said, automounters are pretty widespread - at least Linux, MacOS X, HP-UX and Suns of any vintage support the Sun automounter map format. What clients do you have? Alright, let's try automount. It seems it does not really do /export/mail/m/e/X/Y very well, so I would have to list 0/0 - 9/9 each, so 100 lines in automount. Probably that would be possible, just not very attractive. * /export/mail/m/e/0/0/ . . * /export/mail/m/e/9/9/ If your setup is very dynamic (with mail accounts created or deleted daily), it could be painful. If so, you could perhaps use a map computed on the fly instead of pushing one out through NIS or LDAP, or use /net which is in effect computed on the fly. *** nfsv4 There were some noise about future support that will let you cross file-systems to nfsv4 (mirror mounts). But this doesn't seem to exist right now. It would also cut out any old systems, and any Unix flavour that does not yet do nfsv4 and mirror mounts. Nevada build 77 has this on Solaris; I can't give you versions you would need on other operating systems offhand, but could research it if you care to tell me what clients you run. Answer: x4500 can not replace NetApp in our setup. We would either have to go without quotas, or, cut out any old Unix server versions, or non-Solaris Unix flavours. x4500 is simply not a real NFS server (because we want quotas). I think this conclusions is hasty. Rob T ___ zfs-discuss mailing list zfs-discuss@opensolaris.org http://mail.opensolaris.org/mailman/listinfo/zfs-discuss
Re: [zfs-discuss] Trial x4500, zfs with NFS and quotas.
Jorgen Lundman wrote: Software we use are the usual. Postfix with dovecot, apache with double-hash, https with TLS/SNI, LDAP for provisioning, pure-ftpd, DLZ, freeradius. No local config changes needed for any setup, just ldap and netapp. I meant your client operating systems, actually. The apps don't care so much, especially if they already use NFS. Rob T ___ zfs-discuss mailing list zfs-discuss@opensolaris.org http://mail.opensolaris.org/mailman/listinfo/zfs-discuss
Re: [zfs-discuss] Trial x4500, zfs with NFS and quotas.
Jorgen Lundman wrote: NFSv4 will let the client cross mount points transparently; this is implemented in Nevada build 77, and in Linux and AIX. Looks like I have 70b only. Wonder what the chances are of another release coming out in the 2 month trial period. Does only the x4500 need to run Nevada 77, or would all NFS clients also need to support it? SXCE is coming out _very_ soon. But all of your clients need to support NFSv4 mount point crossing to make full use of it, unless the automounter works out well enough. Rob T ___ zfs-discuss mailing list zfs-discuss@opensolaris.org http://mail.opensolaris.org/mailman/listinfo/zfs-discuss
Re: [zfs-discuss] ZFS or NFS?
Ian Collins wrote: I have a build 62 system with a zone that NFS mounts an ZFS filesystem. From the zone, I keep seeing issues with .nfs files remaining in otherwise empty directories preventing their deletion. The files appear to be immediately replaced when they are deleted. Is this an NFS or a ZFS issue? This is the NFS client keeping unlinked but open files around. You need to find out what process has the files open (perhaps with fuser -c) and persuade them to close the files before you can unmount gracefully. You may also use umount -f if you don't care what happens to the processes. Rob T ___ zfs-discuss mailing list zfs-discuss@opensolaris.org http://mail.opensolaris.org/mailman/listinfo/zfs-discuss
Re: [zfs-discuss] An Academic Sysadmin's Lament for ZFS ?
[EMAIL PROTECTED] wrote: For NFSv2/v3, there's no easy answers. Some have experimented with executable automounter maps that build a list of filesystems on the fly, but ick. At some point, some of the global namespace ideas we kick around may benefit NFSv2/v3 as well. The question for me is: why does this work for /net mounts (to a point, of course) and why can't we emulate this for other mount points? Mounts under /net are derived from the filesystems actually shared from the servers; the automount daemon uses the MOUNT protocol to determine this. If you're looking at a path not already seen, the information will be fresh, but that's where the good news ends. We don't refresh this information reliably, so if you add a new share in a directory we've already scanned, you won't see it until the mounts time out and are removed. We should refresh this data more readily and no matter what the source of data. Rob T ___ zfs-discuss mailing list zfs-discuss@opensolaris.org http://mail.opensolaris.org/mailman/listinfo/zfs-discuss
Re: [zfs-discuss] An Academic Sysadmin's Lament for ZFS ?
Alec Muffett wrote: But finally, and this is the critical problem, each user's home directory is now a separate NFS share. At first look that final point doesn't seem to be much of a worry until you look at the implications that brings. To cope with a distributed system with a large number of users the only managable way of handling NFS mounts is via an automounter. The only alternative would be to have an fstab/vfstab file holding every filesystem any user might want. In the past this has been no problem at all, for all your user home directories on a server you could just export the parent directory holding all the user home directories and put a line users -rw,intr myserver:/disks/users and it would work happily. Now, with each user having a separate filesystem this breaks. The automounter will mount the parent filesystem as before but all you will see are the stub directories ready for the ZFS daughter filesystems to mount onto and there's no way of consolidating the ZFS filesystem tree into one NFS share or rules in automount map files to be able to do sub-directory mounting. Sun's NFS team is close to putting back a fix to the Nevada NFS client for this where a single mount of the root of a ZFS tree lets you wander into the daughter filesystems on demand, without automounter configuration. You have to be using NFSv4, since it relies on the server namespace protocol feature. Some other NFSv4 clients already do this. This has always been a part of the plan to cope with more right-sized filesystems, we've just not there yet. For NFSv2/v3, there's no easy answers. Some have experimented with executable automounter maps that build a list of filesystems on the fly, but ick. At some point, some of the global namespace ideas we kick around may benefit NFSv2/v3 as well. Rob T ___ zfs-discuss mailing list zfs-discuss@opensolaris.org http://mail.opensolaris.org/mailman/listinfo/zfs-discuss
Re: [zfs-discuss] ZFS Time
Robert Olinski wrote: I have a customer who is running into bug 6538387. This is a problem with HP-UX clients accessing NFS mounts which are on a ZFS file system. This has to do with ZFS using nanosecond times and the HP client does not use this amount of precision. This is not an issue with ufs as it does not support this precision either. I investigated this bug, and there's tracks on the nfs-discuss alias. Here's a summary of the situation. The HP client is programmed to use a guard on the SETATTR operation; it echos a server-generated timestamp and asks the server to make sure it's correct. The purpose of this is to make sure the client has the correct file, not one another client may have created. The root cause of 6538387 is that the HP-UX client is storing that timestamp value with only microsecond precision, so the fact that ZFS has nanosecond precision means the client's request doesn't match. Per RFC 1813, the SETATTR op needs to fail. This is referring to the sattrguard3 field for SETATTR in /usr/include/rpcsvc/nfs_prot.x if you want to have a look. The fix available in HP-UX 11.31 could expand their attribute cache to handle full precision, or it could simply retry by doing a GETATTR and keeping the encoded value around for that. Does anyone know what this extra precision in time does for ZFS? The sales group thinks that there should be an option to turn this off. ZFS stores file timestamps (struct timespec), with nanosecond precision. Since the on-disk format was new and didn't have arbitrary limits, and since the system has that precision available, it would take more code to throw precision away than to keep it. As systems get faster, the precision will find uses. With this kind of problem, the proper fix is to change the client. To change it on the server, we would need to either dumb-down ZFS to throw away precision, or hack the NFS server to accept a value that's illegal per the RFC. With HP-UX 11.31 available, I would not support changing Solaris ZFS or NFS to address this. Rob T ___ zfs-discuss mailing list zfs-discuss@opensolaris.org http://mail.opensolaris.org/mailman/listinfo/zfs-discuss
Re: [zfs-discuss] Rsync update to ZFS server over SSH faster than over NFS?
Albert Chin wrote: Why can't the NFS performance match that of SSH? One big reason is that the sending CPU has to do all the comparisons to compute the list of files to be sent - it has to fetch the attributes from both local and remote and compare timestamps. With ssh, local processes at each end do lstat() calls in parallel and chatter about the timestamps, and the lstat() calls are much cheaper. I would wonder how long the attr-chatter takes in your two cases before bulk data starts to be sent - deducting that should reduce the imbalance you're seeing. If rsync were more multi-threaded and could manage multiple lstat() calls in parallel NFS would be closer. Rob T ___ zfs-discuss mailing list zfs-discuss@opensolaris.org http://mail.opensolaris.org/mailman/listinfo/zfs-discuss
Re: [zfs-discuss] Rsync update to ZFS server over SSH faster than over NFS?
Albert Chin wrote: Well, there is no data on the file server as this is an initial copy, Sorry Albert, I should have noticed that from your e-mail :-( I think the bigger problem is the NFS performance penalty so we'll go lurk somewhere else to find out what the problem is. Is this with Solaris 10 or OpenSolaris on the client as well? I guess this goes back to some of the why is tar slow over NFS discussions we've had, some here and some on nfs-discuss. A more multi-threaded workload would help; so will planned work to focus on performance of NFS and ZFS together, which can sometimes be slower than expected. Rob T ___ zfs-discuss mailing list zfs-discuss@opensolaris.org http://mail.opensolaris.org/mailman/listinfo/zfs-discuss
Re: [zfs-discuss] Will this work?
mike wrote: this is exactly the kind of feedback i was hoping for. i'm wondering if some people consider firewire to be better in opensolaris? I've written some about a 4-drive Firewire-attached box based on the Oxford 911 chipset, and I've had I/O grind to a halt in the face of media errors - see bugid 6539587. I haven't played with USB drives enough to trust them more, but this was a hole I fell in with Firewire. I've had fabulous luck with a Firewire attached DVD burner, though. Rob T ___ zfs-discuss mailing list zfs-discuss@opensolaris.org http://mail.opensolaris.org/mailman/listinfo/zfs-discuss
Re: [zfs-discuss] ZFS raid on removable media for backups/temporary use possible?
Tom Buskey wrote: How well does ZFS work on removable media? In a RAID configuration? Are there issues with matching device names to disks? I've had a zpool with 4-250Gb IDE drives in three places recently: - in an external 4-bay Firewire case, attached to a Sparc box - inside a dual-Opteron white box, connected to a 2-channel add-in IDE controller - inside the dual-Opteron, connected via 4 IDE-to-SATA convertors to the motherboard's built-in SATA controller In each case, once 'format' found the drives, ZFS was easily able to import the pool without any fuss or issues. Performance was miserable when running off the add-in IDE controller, but great in the other two cases. As far as I can see, this stuff generally just works. Rob T ___ zfs-discuss mailing list zfs-discuss@opensolaris.org http://mail.opensolaris.org/mailman/listinfo/zfs-discuss
Re: [zfs-discuss] Preferred backup mechanism for ZFS?
Nicolas Williams wrote: Also, why not just punt to NDMP? While I like NDMP, the protocol is just a transport for blobs of data in vendor-specific data formats. We could put a ufsdump or star or 'zfs send' bag-o-bits in there, and call it ours. So it's a part of a solution, but not a complete thing. Rob T ___ zfs-discuss mailing list zfs-discuss@opensolaris.org http://mail.opensolaris.org/mailman/listinfo/zfs-discuss
Re: [zfs-discuss] zfs sharing
Jens Elkner wrote: The only problem I encountered with this approach was with pkgmk: If e.g. /develop/lnf/i386 is not mounted, when it runs, pkgmk doesn't trigger an automount and thinks, the target FS has a size of 0 bytes - no space available. However a short cd /develop/lnf/i386 ; cd - before pkgmk solves that problem. Another trick for this is to use a path of /develop/lnf/i386/. which will trigger an automount because of the lookup of '.'. One of my favorite automounter tricks :-) Rob T ___ zfs-discuss mailing list [EMAIL PROTECTED] http://mail.opensolaris.org/mailman/listinfo/zfs-discuss
Re: [zfs-discuss] zfs sharing
Anthony J. Scarpino wrote: I'm not sure if this is an nfs/autofs problem or zfs problem... But I'll try here first... On our server, I've got a zfs directory called cube/builds/izick/. In this directory I have a number of mountpoints to other zfs file systems.. The problem happens when we clone a new zfs file system, say cube/builds/izick/foo, any client system that already have cube/builds/izick mounted, can see the new directory foo, but cannot see the contents. It looks like a blank directory on the client systems, but on the server it would be fully populated with data.. All the zfs file systems are shared.. Restarting autofs and nfs/client does nothing.. The only way to fix this is to unmount the directory on the client, which can be invasive to a desktop machine.. Could there be a problem because the zfs files systems are nested? Is there a known issue with zfs-nfs interactions where zfs doesn't tell nfs properly that there has been an update, other than the just the mountpoint? thanks... This is a known limitation - you would need to add entries to your automounter maps to let the client know to do mounts for those 'nested' entries. We're working on it - since the client can see the new directories and detect that they're different filesystems, we could do what we call 'mirror mounts' to make them available. See http://opensolaris.org/os/project/nfs-namespace/ for more on this and other work. Rob T ___ zfs-discuss mailing list zfs-discuss@opensolaris.org http://mail.opensolaris.org/mailman/listinfo/zfs-discuss
Re: [zfs-discuss] zfs sharing
Anthony Scarpino wrote: [EMAIL PROTECTED] wrote: Anthony J. Scarpino wrote: I'm not sure if this is an nfs/autofs problem or zfs problem... But I'll try here first... On our server, I've got a zfs directory called cube/builds/izick/. In this directory I have a number of mountpoints to other zfs file systems.. The problem happens when we clone a new zfs file system, say cube/builds/izick/foo, any client system that already have cube/builds/izick mounted, can see the new directory foo, but cannot see the contents. It looks like a blank directory on the client systems, but on the server it would be fully populated with data.. All the zfs file systems are shared.. Restarting autofs and nfs/client does nothing.. The only way to fix this is to unmount the directory on the client, which can be invasive to a desktop machine.. Could there be a problem because the zfs files systems are nested? Is there a known issue with zfs-nfs interactions where zfs doesn't tell nfs properly that there has been an update, other than the just the mountpoint? thanks... This is a known limitation - you would need to add entries to your automounter maps to let the client know to do mounts for those 'nested' entries. We're working on it - since the client can see the new directories and detect that they're different filesystems, we could do what we call 'mirror mounts' to make them available. See http://opensolaris.org/os/project/nfs-namespace/ for more on this and other work. Rob T Ok... thanks for the link.. I'm happy this is known and being worked on.. Any targets yet when this would integrated? Early summer, we hope :-) Rob T ___ zfs-discuss mailing list zfs-discuss@opensolaris.org http://mail.opensolaris.org/mailman/listinfo/zfs-discuss
Re: [zfs-discuss] Best way to migrate filesystems to ZFS?
Richard Elling wrote: Peter Eriksson wrote: ufsdump/ufsrestore doesn't restore the ACLs so that doesn't work, same with rsync. ufsrestore obviously won't work on ZFS. ufsrestore works fine; it only reads from a 'ufsdump' format medium and writes through generic filesystem APIs. I did some of this last week. ACLs, as noted, won't get written out to ZFS. Rob T ___ zfs-discuss mailing list zfs-discuss@opensolaris.org http://mail.opensolaris.org/mailman/listinfo/zfs-discuss
[zfs-discuss] Pathological ZFS performance
Hi folks, In some prior posts, I've talked about trying to get four IDE drives in a Firewire case working. Yesterday, I bailed out due to hangs, filed 6539587, and moved the drives inside my Opteron box, hanging off one of these: http://www.newegg.com/Product/Product.asp?Item=N82E16816124001 Now, I know the single IDE controller is going to be a bottleneck, but let me tell you how slow it is. Last night, after moving the drives, I started a scrub. It's still running. At 20 hours, I was up to 57.75%, and had 14.5 hours left. That's for a pool that's 341Gb, so the scrub has to access 341 * 4 / 3, or 454Gb. I make that something under 4 Megabytes per second. That's not just slow, it's pathological. I was easily getting 10-20X from this pool in the external case. Where do I get started at diagnosing this? I don't know much about watching I/O throughput. For yet-another-fallback, I am thinking about using SATA-to-IDE converters here: http://www.newegg.com/product/product.asp?item=N82E16812156010 It feels kind of nuts, but I have to think this would perform better than what I have now. This would cost me the one SATA drive I'm using now in a smaller pool. Rob T ___ zfs-discuss mailing list zfs-discuss@opensolaris.org http://mail.opensolaris.org/mailman/listinfo/zfs-discuss
Re: [zfs-discuss] Pathological ZFS performance
Bill Sommerfeld wrote: On Fri, 2007-03-30 at 06:12 -0600, Robert Thurlow wrote: Last night, after moving the drives, I started a scrub. It's still running. At 20 hours, I was up to 57.75%, and had 14.5 hours left. Do you have any cron jobs which are creating periodic snapshots? No, not in this case. I remember that bug. My scrub made linear progress the whole way. RT ___ zfs-discuss mailing list zfs-discuss@opensolaris.org http://mail.opensolaris.org/mailman/listinfo/zfs-discuss
[zfs-discuss] Pool problem
I have this external Firewire box with 4 IDE drives in it, attached to a Sunblade 2500. I've built the following pool on them: banff[1]% zpool status pool: pond state: ONLINE scrub: none requested config: NAME STATE READ WRITE CKSUM pond ONLINE 0 0 0 raidz1 ONLINE 0 0 0 c10t0d0 ONLINE 0 0 0 c10t0d1 ONLINE 0 0 0 c11t0d0 ONLINE 0 0 0 c11t0d1 ONLINE 0 0 0 errors: No known data errors I've partly filled it with data to stress it, and now when I run a 'zpool scrub', it gets to this point and stops: banff[13]# zpool status pool: pond state: ONLINE status: One or more devices has experienced an unrecoverable error. An attempt was made to correct the error. Applications are unaffected. action: Determine if the device needs to be replaced, and clear the errors using 'zpool clear' or replace the device with 'zpool replace'. see: http://www.sun.com/msg/ZFS-8000-9P scrub: scrub in progress, 35.30% done, 4h3m to go This is usually followed with repeated complaints on the console: Mar 19 18:46:30 banff scsi: WARNING: /[EMAIL PROTECTED],60/[EMAIL PROTECTED]/[EMAIL PROTECTED]/[EMAIL PROTECTED]/[EMAIL PROTECTED],0 (sd10): Mar 19 18:46:30 banff Error for Command: read(10)Error Level: Retryable Mar 19 18:46:30 banff scsi: Requested Block: 218914280 Error Block: 218914280 Mar 19 18:46:30 banff scsi: Vendor: WDC WD25 Serial Number: Mar 19 18:46:30 banff scsi: Sense Key: Media_Error Mar 19 18:46:30 banff scsi: ASC: 0x4b (data phase error), ASCQ: 0x0, FRU: 0x0 (repeats four times) Mar 19 18:47:33 banff scsi: WARNING: /[EMAIL PROTECTED],60/[EMAIL PROTECTED]/[EMAIL PROTECTED]/[EMAIL PROTECTED]/[EMAIL PROTECTED],1 (sd11): Mar 19 18:47:33 banff SCSI transport failed: reason 'reset': retrying command Mar 19 19:01:36 banff scsi: WARNING: /[EMAIL PROTECTED],60/[EMAIL PROTECTED]/[EMAIL PROTECTED]/[EMAIL PROTECTED]/[EMAIL PROTECTED],0 (sd10): Mar 19 19:01:36 banff SCSI transport failed: reason 'reset': giving up Mar 19 19:09:34 banff scsi: WARNING: /[EMAIL PROTECTED],60/[EMAIL PROTECTED]/[EMAIL PROTECTED]/[EMAIL PROTECTED]/[EMAIL PROTECTED],1 (sd11): Mar 19 19:09:34 banff SCSI transport failed: reason 'reset': giving up Mar 19 19:12:37 banff scsi: WARNING: /[EMAIL PROTECTED],60/[EMAIL PROTECTED]/[EMAIL PROTECTED]/[EMAIL PROTECTED]/[EMAIL PROTECTED],0 (sd10): Mar 19 19:12:37 banff SCSI transport failed: reason 'reset': giving up After getting one of these, the machine and the storage never manage to work it out and resume; all access grinds to a halt until I reboot the server. I also see the same blocks failing on the same disks, and I'm surprised bad block mapping doesn't manage to come into play. I tried writing a zero to one of the drives to try to force this, but it didn't help: banff[20]# dd if=/dev/zero of=/dev/rdsk/c10t0d0 oseek=218914280 count=1 Help? I don't understand why zfs isn't handling this. I do not have confidence that the external case is my friend here (more about that in another post), but I'm surprised at this failure mode. Thanks, Rob T ___ zfs-discuss mailing list zfs-discuss@opensolaris.org http://mail.opensolaris.org/mailman/listinfo/zfs-discuss
Re: [zfs-discuss] ZFS filesystem disappeared after reboot?
Darren Reed wrote: Using Solaris 10, Update 2 I've just rebooted my desktop and I have discovered that a ZFS filesystem appears to have gone missing. The filesystem in question was called biscuit/home and should have been modified to have its mountpoint set to /export/home. Is there any way I can try to discover if it was my fingers before the reboot or if ZFS gobbled it up by mistake? zfs list should show it. Try zfs mount -a and check to see if it gets mounted or gives you an error, since zfs won't mount over things like automounted filesystems or existing directories. Rob T ___ zfs-discuss mailing list zfs-discuss@opensolaris.org http://mail.opensolaris.org/mailman/listinfo/zfs-discuss
Re: [zfs-discuss] Re: ZFS and Firewire/USB enclosures
Jürgen Keil wrote: I still haven't got any warm and fuzzy responses yet solidifying ZFS in combination with Firewire or USB enclosures. I was unable to use zfs (that is zpool create or mkfs -F ufs) on firewire devices, because scsa1394 would hang the system as soon as multiple concurrent write commands are submitted to it. I've had better luck than that in that my zpool create worked and the first data copy (23085 MP3 files, 105Gb) worked very well. But yes, stress can lock things up nicely on build 51. I filed bug 6445725 (which disappeared in the scsa1394 bugs.opensolaris.org black hole), submitted a fix and requested a sponsor for the fix[*], but not much has happened with fixing this problem in opensolaris. Let me poke the sponsor about it. It's a P4 now, which I don't think is high enough. I'd also like to try your fix on my box :-) Rob T ___ zfs-discuss mailing list zfs-discuss@opensolaris.org http://mail.opensolaris.org/mailman/listinfo/zfs-discuss
[zfs-discuss] Low-end JBOD - am I nuts?
Hi all, My disk resources are all getting full again, so it must be time to buy more storage :-) I'm using ZFS at home, and it's worked great on the concat of a 74Gb IDE and a 74 Gb SATA drive, especially with redundant meta-data. That's puny compared to some of the external storage bricks I see out there. But it would be nice to get some actual redundancy, wouldn't it? What I've been looking for, and might have found now, is a cheap way to house 3-4 spindles in a single case connected by Firewire to my choice of three different machines. I don't really want to buy eSATA cards for them all (and one's a laptop anyway), and I'd put ordinary retail IDE or SATA drives in it. With 250Gb drives selling for $70 on newegg.com, all I have to do is to keep the price of the enclosure under control and I can almost match the cost of a single-spindle 750Gb external drive and get a Raid-Z out of the deal (say a total of $500). The Firewire 400 case I'm looking at (for $150) is here: http://cgi.ebay.com/ws/eBayISAPI.dll?ViewItemrd=1item=120030189937 They have an Ebay storefront here: http://stores.ebay.com/Superldg-Store They would also sell me Firewire 800 (which none of my current machines happen to support), SATA instead of IDE, and sets with different numbers of exposed Firewire connectors if your heart desires them. I don't know that I care about the difference between an IDE and a SATA drive at this price point. I know nobody can speak to the case I'm talking about, but does anyone have experience with ZFS on Firewire-attached drives? And does anyone have an alternate low-end JBOD solution that's about in this ballpark? I'm surprised to not see more of them offered for sale, without all the RAID cruft that of course I don't want anyway. Thanks, Rob T ___ zfs-discuss mailing list zfs-discuss@opensolaris.org http://mail.opensolaris.org/mailman/listinfo/zfs-discuss
Re: [zfs-discuss] UFS on zvol: volblocksize and maxcontig
Eric Enright wrote: Samba does not currently support ZFS ACLs. Yes, but this just means you can't get/set your ACLs from a CIFS client. ACLs will be enforced just fine once set locally on the server; you may also be able to get/set them from an NFS client. You may know this, but I know some are confused by this and think you lose ACL protection. Rob T ___ zfs-discuss mailing list zfs-discuss@opensolaris.org http://mail.opensolaris.org/mailman/listinfo/zfs-discuss
Re: [zfs-discuss] zfs sharenfs inheritance
Robert Petkus wrote: When using sharenfs, do I really need to NFS export the parent zfs filesystem *and* all of its children? For example, if I have /zfshome /zfshome/user1 /zfshome/user1+n it seems to me like I need to mount each of these exported filesystems individually on the NFS client. This scheme doesn't seem optimal. If I have tens of thousands of users, each with their own little ZFS filesystem (necessary because ZFS doesn't do user-based quotas), I don't want to NFS mount all of these filesystems on a single node. Most people use an automounter to mount NFS filesystems on demand to solve an issue like this. Getting changes to maps distributed does get more painful with a lot more distinct filesystems, but being able to mount only what you need can be quite a good thing. An alternate way will be to use NFSv4. When an NFSv4 client crosses a mountpoint on the server, it can detect this and mount the filesystem. It can feel like a lite version of the automounter in practice, as you just have to mount the root and discover the filesystems as needed. The Solaris NFSv4 client can't do this yet. Rob T ___ zfs-discuss mailing list zfs-discuss@opensolaris.org http://mail.opensolaris.org/mailman/listinfo/zfs-discuss
