From owner-freebsd-fs@freebsd.org Wed Sep 9 16:52:19 2015 Return-Path: Delivered-To: freebsd-fs@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id E86BEA0132C for ; Wed, 9 Sep 2015 16:52:19 +0000 (UTC) (envelope-from jordanhubbard@icloud.com) Received: from pv33p03im-asmtp001.me.com (pv33p03im-asmtp001.me.com [17.143.180.10]) (using TLSv1.2 with cipher DHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id C0A9713DE for ; Wed, 9 Sep 2015 16:52:19 +0000 (UTC) (envelope-from jordanhubbard@icloud.com) Received: from [10.20.30.60] (75-101-82-48.static.sonic.net [75.101.82.48]) by pv33p03im-asmtp001.me.com (Oracle Communications Messaging Server 7.0.5.35.0 64bit (built Mar 31 2015)) with ESMTPSA id <0NUF00FIX5IMW040@pv33p03im-asmtp001.me.com> for freebsd-fs@freebsd.org; Wed, 09 Sep 2015 16:52:05 +0000 (GMT) X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:,, definitions=2015-09-09_09:,, signatures=0 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 kscore.is_bulkscore=3.13944348295792e-09 compositescore=0.994460221061599 phishscore=0 kscore.is_spamscore=0 rbsscore=0.994460221061599 recipient_to_sender_totalscore=0 spamscore=0 urlsuspectscore=0.994460221061599 adultscore=0 kscore.compositescore=0 circleOfTrustscore=0 suspectscore=0 recipient_domain_to_sender_totalscore=0 bulkscore=0 recipient_domain_to_sender_domain_totalscore=0 recipient_to_sender_domain_totalscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1412110000 definitions=main-1509090240 Content-type: text/plain; charset=utf-8 MIME-version: 1.0 (Mac OS X Mail 9.0 \(3093\)) Subject: Re: CEPH + FreeBSD From: Jordan Hubbard In-reply-to: Date: Wed, 09 Sep 2015 09:51:57 -0700 Cc: Mark Saad , freebsd-fs@freebsd.org Content-transfer-encoding: quoted-printable Message-id: References: <100306673.40344407.1441279047901.JavaMail.zimbra@uoguelph.ca> <1564D4FA-9BE1-4E37-8E91-F14A009D6B62@icloud.com> <838814506.1858817.1441577912291.JavaMail.zimbra@uoguelph.ca> <8551C101-0E4B-4619-BF52-1B87BC6565D8@longcount.org> To: Rakshith Venkatesh X-Mailer: Apple Mail (2.3093) X-BeenThere: freebsd-fs@freebsd.org X-Mailman-Version: 2.1.20 Precedence: list List-Id: Filesystems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 09 Sep 2015 16:52:20 -0000 > On Sep 8, 2015, at 7:29 PM, Rakshith Venkatesh = wrote: >=20 > If there is a need to support cifs along with NFS then locking surely = is > needed to maintain data sanity and avoid problems due to concurrent = access > to files. Well, sort of. The file sharing semantics between NFS and CIFS are so = different in not just in how they lock files, but in the Windows vs Unix = permission models, that it=E2=80=99s essentially lunatic to attempt to = share the same ZFS dataset to both NFS and Windows clients. FreeNAS does not even allow you to do that - you pick a dataset for CIFS = sharing and it applies a completely different set of default ACLs and = even goes so far as to disable Unix permission changes (chown/chmod) = completely so that clueless system admins don=E2=80=99t do local Unix = permission operations on the files and end up blowing certainly critical = (to Windows) ACLs off, rendering the share unusable to Windows clients. = It happened so often that we ultimately had to lay down the law and = explicitly disallow that scenario. In the past, Samba3 also used to essentially lie about a lot of the Unix = permissions to Windows clients in order to provide some semblance of = interoperability, but that ended up causing more problems than it solved = (it=E2=80=99s better to be predictable than magical) and in Samba4, = it=E2=80=99s far more inclined to simply tell the truth, which also = tripped up a lot of sysadmins who were used to it lying before. Once = they managed to unscramble their permissions and actually leverage ACLs = to the full extent they were meant to be used, they learned what the = Samba team already knew: NFS ACLs !=3D Windows ACLs. Or, as they said it best in Ghostbusters: Egon Spengler: There's something very important I forgot to tell you. Peter Venkman: What? Spengler: Don't cross the streams. Venkman: Why? Spengler: It would be bad. Venkman: I'm fuzzy on the whole good/bad thing. What do you mean, "bad"? Spengler: Try to imagine all life as you know it stopping = instantaneously and every molecule in your body exploding at the speed = of light. Ray Stantz: Total protonic reversal! Venkman: Right. That's bad. Okay. All right. Important safety tip. = Thanks, Egon. So yeah, the dream of sharing CIFS and NFS from the same dataset is = probably never going to be a reality. I mean, it=E2=80=99s *technically = possible* just like all things are technically possible, but you=E2=80=99d= have to come up with some sort of underlying =E2=80=9CUniversal = permissions and locking model=E2=80=9D that could then be mapped and = translated upwards to both Unix and Windows clients such that each saw = exactly what they wanted and needed to see, and then you=E2=80=99d need = to commit to maintaining that model across multiple versions of Windows = (in which the semantics have changed in subtle ways over time) and Unix. = The Samba folks really tried to fake that up in userland and as near as = I can figure out, they eventually realized it was just a terrible place = to be and stopped trying to force incompatible species to live together, = which is what we also decided. Yeah, it kind of sucks not being able to = share exactly the same files for R/W access to both Windows and Unix = clients simultaneously. Deal with it. Life is cruel. :-) JFYI, - Jordan