Re: [zfs-discuss] Any HP Servers recommendation for Openindiana (Capacity Server) ?
2012/1/3 Christopher Hearn christopher.he...@cchmc.org: On Jan 3, 2012, at 9:35 AM, Svavar Örn Eysteinsson wrote: Hello. I'm planing to replace my old Apple XRAID, and XSAN Filesystem(1.4.2) Fiber environment. This setup only hosted a AFP,CIFS for a large advertising agency. Now that Fiber is damn expensive and for one thing, we do not need the fiber connection as every client connects with IP. So iSCSI, AFP, CIFS should be efficient for us. We have been running this setup since late/early 2006/2007 without problems. No that the hardware/software is warned out and we had pretty damn catastropic filesystem failure lately. I've been running OpenIndiana on a custom made server with ZFS,CIFS,AFP and all that for couple of months right now. Really good. This server just acts as a temporary solution. Currently has 4x 2TB Enterprise SATA disks in RAIDz1 and expanding in few weeks with Supermicro AOC-USAS-L8i and 4-8 more disks. Doing daily snapshots and, yea really love it. Are there any recommendations regarding HP Servers running OpenIndiana to act as a ZFS Capacity server ? The server should only do : * AFP * CIFS * NFS * iSCSI * and of course ZFS underneath So what I'm looking at is a large capacity server. We need 12-20TB at the start. Any other vendors good ? any servers that comes out of the box and runs Openindiana 151 with no problems (drivers / hardware ) e.t.c. acting as a capacity server. And support would be a good option to. Any help would be much appreciated. Thanks allot. Best regards, Svavar - Reykjavik - Iceland I haven't really seen any 100% commercially supported solutions for this. If you put this configuration on an HP server call them to report a problem, they're going to most likely deny your request because you're using an unsupported OS. You may be able to get away with using Solaris 11, but you'll pay for it. I suggest looking at NexentaStor it's partners: http://www.nexenta.com. One of them being: http://www.racktopsystems.com/products/brickstor/brickstor-models/ Afaik they're in the process of announing official AFP support (with Netatalk) soon. -f ___ zfs-discuss mailing list zfs-discuss@opensolaris.org http://mail.opensolaris.org/mailman/listinfo/zfs-discuss
Re: [zfs-discuss] NFS acl inherit problem
2011/6/1 lance wilson lance.wil...@gmail.com: The problem is that nfs clients that connect to my solaris 11 express server are not inheriting the acl's that are set for the share. They create files that don't have any acl assigned to them, just the normal unix file permissions. Can someone please provide some additional things to test so that I can get this sorted out. Expected behaviour. http://mail.opensolaris.org/pipermail/zfs-discuss/2010-September/045120.html -f ___ zfs-discuss mailing list zfs-discuss@opensolaris.org http://mail.opensolaris.org/mailman/listinfo/zfs-discuss
Re: [zfs-discuss] aclmode - no zfs in heterogeneous networks anymore?
2011/4/26 achim...@googlemail.com achim...@googlemail.com: -BEGIN PGP SIGNED MESSAGE- Hash: SHA256 Hi! We are setting up a new file server on an OpenIndiana box (oi_148). The spool is run-in version 28, so the aclmode option is gone. The server has to serve files to Linux, OSX and windows. Because of the missing aclmode option, we are getting nuts with the file permissions. I read a whole lot about the problem and the pros and cons of the decision of dropping that option in zfs, but I absolutely read nothing about a solution or work around. The problem is, that gnome's nautilus as well as OSX' finder perform a chmod after writing a file over ifs, causing all ACLs to vanish. If there is no solution, zfs seems to be dead. How do you solve this problem? Using Netatalk for giving Macs native AFP support. Latest Netatalk has a workaround (basically a chmod(3) wrapper) builtin. Best! -f ___ zfs-discuss mailing list zfs-discuss@opensolaris.org http://mail.opensolaris.org/mailman/listinfo/zfs-discuss
Re: [zfs-discuss] Changed ACL behavior in snv_151 ?
2011/1/27 Ryan John john.r...@bsse.ethz.ch: -Original Message- From: Frank Lahm [mailto:frankl...@googlemail.com] Sent: 25 January 2011 14:50 To: Ryan John Cc: zfs-discuss@opensolaris.org Subject: Re: [zfs-discuss] Changed ACL behavior in snv_151 ? John, welcome onboard! 2011/1/25 Ryan John john.r...@bsse.ethz.ch: I’m sharing file systems using a smb and nfs, and since I’ve upgraded to snv_151, when I do a chmod from an NFS client, I lose all the NFSv4 ACLs. http://opensolaris.org/jive/thread.jspa?threadID=134162 I'd summarize as follows: in order to play nice with Windows ACL semantics via builtin CIFS, they choose the approach of throwing away ACLs on chmod(). Makes Windows happy, others not so. This really breaks our whole setup. Under snv_134 our users were happy with Windows ACLs, and NFSv3 and NFSv4 Linux clients. They all worked very well together. The only problem we had with the deny ACLs, was when using the MacOS Finder You could try Netatalk for access from Macs. The OS X AFP VFS plugin is far more forgiving then the CIFS one, making AFP still the file sharing protocol of choice for Macs. We've implemented a workaround for this chmod() vs ACL problem in (afair) Netatlk 2.1.5. For easy-to-use ACL support, you could give the just released 2.2-beta1 a try. Was it a result of PSARC/2009/029 ? http://arc.opensolaris.org/caselog/PSARC/2010/029/20100126_mark.shellenbaum Afair, yes. If so, I think that was implemented around snv_137. Yes. -f ___ zfs-discuss mailing list zfs-discuss@opensolaris.org http://mail.opensolaris.org/mailman/listinfo/zfs-discuss
Re: [zfs-discuss] Changed ACL behavior in snv_151 ?
2011/1/27 Garrett D'Amore garr...@nexenta.com: We are working on a change to illumos (and NexentaStor) to revive acl_mode... lots and lots of people have had very bad experiences as a result of that particular change. We had to put a chmod() wrapper into our app (Netatalk) to work around that. Good to hear your planning to tackle this OS side. -f ___ zfs-discuss mailing list zfs-discuss@opensolaris.org http://mail.opensolaris.org/mailman/listinfo/zfs-discuss
Re: [zfs-discuss] Changed ACL behavior in snv_151 ?
John, welcome onboard! 2011/1/25 Ryan John john.r...@bsse.ethz.ch: I’m sharing file systems using a smb and nfs, and since I’ve upgraded to snv_151, when I do a chmod from an NFS client, I lose all the NFSv4 ACLs. http://opensolaris.org/jive/thread.jspa?threadID=134162 I'd summarize as follows: in order to play nice with Windows ACL semantics via builtin CIFS, they choose the approach of throwing away ACLs on chmod(). Makes Windows happy, others not so. -f ___ zfs-discuss mailing list zfs-discuss@opensolaris.org http://mail.opensolaris.org/mailman/listinfo/zfs-discuss
Re: [zfs-discuss] SAS/short stroking vs. SSDs for ZIL
2010/12/24 Edward Ned Harvey opensolarisisdeadlongliveopensola...@nedharvey.com: From: Frank Lahm [mailto:frankl...@googlemail.com] With Netatalk for AFP he _is_ running a database: any AFP server needs to maintain a consistent mapping between _not reused_ catalog node ids (CNIDs) and filesystem objects. Luckily for Apple, HFS[+] and their Cocoa/Carbon APIs provide such a mapping making diirect use of HFS+ CNIDs. Unfortunately most UNIX filesystem reuse inodes and have no API for mapping inodes to filesystem objects. Therefor all AFP servers running on non-Apple OSen maintain a database providing this mapping, in case of Netatalk it's `cnid_dbd` using a BerkeleyDB database. Don't all of those concerns disappear in the event of a reboot? If you stop AFP, you could completely obliterate the BDB database, and restart AFP, and functionally continue from where you left off. Right? No. Apple's APIs provide semantics by which you can reference filesystem objects by their parent directory CNID + object name. More important in this context: these references can be stored, retrieved and reused, eg. Finder Aliasses, Adobe InDesign and many more applications use these semantics to store references to files. If you nuke the CNID database, upon renumeration of the volumes all filesystem objects are likely to assigned new and different CNIDs, thus all references are broken. -f ___ zfs-discuss mailing list zfs-discuss@opensolaris.org http://mail.opensolaris.org/mailman/listinfo/zfs-discuss
Re: [zfs-discuss] SAS/short stroking vs. SSDs for ZIL
2010/12/24 Edward Ned Harvey opensolarisisdeadlongliveopensola...@nedharvey.com: From: zfs-discuss-boun...@opensolaris.org [mailto:zfs-discuss- boun...@opensolaris.org] On Behalf Of Stephan Budach Now, I am wondering if using a mirror of such 15k SAS drives would be a good-enough fit for a ZIL on a zpool that is mainly used for file services via AFP and SMB. For supporting AFP and SMB, most likely, you would be perfectly happy simply disabling the ZIL. You will get maximum performance... Even higher than the world's fastest SSD or DDRDrive or any other type of storage device for dedicated log. To determine if this is ok for you, be aware of the argument *against* disabling the ZIL: In the event of an ungraceful crash, with ZIL enabled, you lose up to 30 sec of async data, but you do not lose any sync data. In the event of an ungraceful crash, with ZIL disabled, you lose up to 30 sec of async and sync data. In neither case do you have data corruption, or a corrupt filesystem. The only question is about 30 seconds of sync data. You must protect this type of data, if you're running a database, ... With Netatalk for AFP he _is_ running a database: any AFP server needs to maintain a consistent mapping between _not reused_ catalog node ids (CNIDs) and filesystem objects. Luckily for Apple, HFS[+] and their Cocoa/Carbon APIs provide such a mapping making diirect use of HFS+ CNIDs. Unfortunately most UNIX filesystem reuse inodes and have no API for mapping inodes to filesystem objects. Therefor all AFP servers running on non-Apple OSen maintain a database providing this mapping, in case of Netatalk it's `cnid_dbd` using a BerkeleyDB database. -f ___ zfs-discuss mailing list zfs-discuss@opensolaris.org http://mail.opensolaris.org/mailman/listinfo/zfs-discuss
Re: [zfs-discuss] No ACL inheritance with aclmode=passthrough in onnv-134
2010/10/25 Cindy Swearingen cindy.swearin...@oracle.com: You can't simulate the aclmode-less world in the upcoming release by setting aclmode to discard in b134. The reason you see your aclmode discarded because aclmode applies to both chmod operations and file/dir create operations. Yes, after re-reading the docs I'd seen that. Must have missed that part before. This is why you are seeing the ACL being discarded. It does not do this in build 147. Looking forward! ;) Thanks! -f ___ zfs-discuss mailing list zfs-discuss@opensolaris.org http://mail.opensolaris.org/mailman/listinfo/zfs-discuss
[zfs-discuss] No ACL inheritance with aclmode=passthrough in onnv-134
Hi list, while preparing for the changed ACL/mode_t mapping semantics coming with onnv-147 [1], I discovered that in onnv-134 on my system ACLs are not inherited when aclmode is set to passthrough for the filesystem. This very much puzzles me. Example: $ uname -a SunOS os 5.11 snv_134 i86pc i386 i86pc $ pwd /Volumes/ACLs/dir1 $ zfs list | grep /Volumes rpool/Volumes 7,00G 39,7G 6,84G /Volumes $ zfs get aclmode,aclinherit rpool/Volumes NAME PROPERTYVALUE SOURCE rpool/Volumes aclmode passthroughlocal rpool/Volumes aclinherit passthroughlocal $ ls -dlV . drwxr-xr-x+ 3 ldapadmin ldapgroup2 3 Okt 23 13:19 . group:ldapgroup1:rwxp--aARWc---:fdi:allow group:ldapgroup1:rwxp--aARWc---:---:allow owner@:--:---:deny owner@:rwxp---A-W-Co-:---:allow group@:-w-p--:---:deny group@:r-x---:---:allow everyone@:-w-p---A-W-Co-:---:deny everyone@:r-x---a-R-c--s:---:allow $ id uid=5001(ldapuser1) gid=5001(ldapgroup1) $ touch file $ ls -lV file -rw-r--r--+ 1 ldapuser1 ldapgroup1 0 Okt 23 13:21 file group:ldapgroup1:rwxp--aARWc---:--I:allow owner@:--x---:---:deny owner@:rw-p---A-W-Co-:---:allow group@:-wxp--:---:deny group@:r-:---:allow everyone@:-wxp---A-W-Co-:---:deny everyone@:r-a-R-c--s:---:allow $ exit # zfs set aclmode=discard rpool/Volumes # su ldapuser1 ldapus...@os:/Volumes/ACLs/dir1$ export PS1=$ $ zfs get aclmode,aclinherit rpool/Volumes NAME PROPERTYVALUE SOURCE rpool/Volumes aclmode discardlocal rpool/Volumes aclinherit passthroughlocal $ touch file2 $ ls -lV file2 -rw-r--r-- 1 ldapuser1 ldapgroup1 0 Okt 23 13:22 file2 owner@:--x---:---:deny owner@:rw-p---A-W-Co-:---:allow group@:-wxp--:---:deny group@:r-:---:allow everyone@:-wxp---A-W-Co-:---:deny everyone@:r-a-R-c--s:---:allow $ truss -v all touch file3 ... stat64(file3, 0x08047BF0) Err#2 ENOENT creat64(file3, 0666) = 3 futimens(3, 0x) = 0 close(3)= 0 _exit(0) touch is not calling chmod(), also the same happens with mkdir.1 (which also doesn't call chmod()). To summarize: ACLs are not inherited when aclmode = discard. Why is this? Afaik this should not be the case. Thanks! -f [1] http://arc.opensolaris.org/caselog/PSARC/2010/029/20100126_mark.shellenbaum ___ zfs-discuss mailing list zfs-discuss@opensolaris.org http://mail.opensolaris.org/mailman/listinfo/zfs-discuss
