From owner-freebsd-hackers@FreeBSD.ORG Tue Nov 26 12:27:46 2013 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 953E0515; Tue, 26 Nov 2013 12:27:46 +0000 (UTC) Received: from mail-pd0-x22e.google.com (mail-pd0-x22e.google.com [IPv6:2607:f8b0:400e:c02::22e]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 6E19129C3; Tue, 26 Nov 2013 12:27:46 +0000 (UTC) Received: by mail-pd0-f174.google.com with SMTP id y13so7564574pdi.19 for ; Tue, 26 Nov 2013 04:27:46 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:date:message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=3xaogLIP2VAB2Y7pOH8Of4XAAkTFXeBAIiiigmeMWrI=; b=eW41jgQyWq4PacGTRW1aGDaJJHHfPLQFkSr1zl8KBSAcjS3yucw0sh10xHTZQBN4tH RHoajFvpTfDJW2lSnzQLSZrw5toml6HiltDtQ1m5ahnJak6KIRROutv8laM1tl22vShZ H40eHBQzR4B5pVWB2722HEmJ9MtICIj+L6ingWAJq5j77vShNahqJqCXLyFlWIDmZTr+ 0OGagIbZdofQg198R11ABZVNqIaj5QoXTMvtvTF3dyDUNFcYFnk4+ywH6UMLBcv6AqDR e2GJZeydm/38ys7odnQ8NlA0FyhuUxDVAUYzN38WJTTHvNaVdvZV6JvBfdRjqP3bjs3a Kt1A== MIME-Version: 1.0 X-Received: by 10.66.147.9 with SMTP id tg9mr34597881pab.5.1385468865905; Tue, 26 Nov 2013 04:27:45 -0800 (PST) Received: by 10.70.64.132 with HTTP; Tue, 26 Nov 2013 04:27:45 -0800 (PST) Date: Tue, 26 Nov 2013 13:27:45 +0100 Message-ID: Subject: Alternate Data Stream Support in FreeBSD (was Re: O_XATTR support in FreeBSD?) From: Lionel Cons To: Freebsd hackers list Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable Cc: Richard Yao , Jordan Hubbard , Pedro Giffuni , Cedric Blancher , Rick Macklem X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.16 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 26 Nov 2013 12:27:46 -0000 On 26 November 2013 11:19, Jordan Hubbard wrote: > > On Nov 26, 2013, at 1:51 AM, Cedric Blancher = wrote: > >> 1. You do not need more syscalls. Solaris uses the plain openat() >> syscall for this, with the O_XATTR flag passed to the normal >> open()/openat() flags to open a named attribute. Likewise read(), >> write(), mmap() etc work, too. > > I don=92t know if I=92d go so far as to say =93you do not need more sysca= lls=94; > there are additional functions for manipulating EAs that go well beyond > the Solaris extensions to the directory and file I/O functions. Assuming= you > want to be able to get/set as well as enumerate or remove EAs, then > you might just as well add getxattr(2), listxattr(2), removexattr(2), set= xattr(2) > too and follow the herd (Linux and OS X, so far). You mean 'follow the lemmings down into the abyss'? :) > We=92re also glossing over ACLs and where they get to live. I don=92t kn= ow if Robert > and friends have stuck them in a separate namespace on FreeBSD or if they= =92re > in system-protected EAs, as they are in OS X, but ACL preservation across > serialization / deserialization is just as important as it is for EAs. Could we first agree what we are talking about, please? I'm a bit new to this thread, but AFAIK we are talking about the Windows Alternate Data Streams as they appear in networked filesystem like NFSv4 and CIFS and physical filesystems like NTFS, ZFS and Solaris UFS, right? ACLs have no direct relation to those streams. The attributes support from Linux has been proven (at least from CERNs viewpoint) as pretty useless because of their size constrains and crappy API (i.e. no mmap(), no sparse support, no normal tools can access them, ...) so IMHO the herd to follow is the herd which implements at least the following requirements: 1) A proper implementation, which includes access using the normal system utilities (in Solaris there is the runat(1) utility to access the hidden directory containing the attribute files, and bash4.3 and ksh have cd -@ to cwd into the hidden directories containing the attribute files. From that point on (inside the hidden directory) ls(1) and even chown(1) and chmod(1) work as usual. You can even stick ZFS and NFSv4 ACLs on the files in the hidden directory containing the attribute files) 2) read(), write() and mmap() access, i.e. the normal POSIX API (of course with the minor extension to flag an access to an alternate data stream or the directory containing the alternate data streams) 2) Support in networked filesystems (i.e. NFSv4, CIFS) 3) No size restrictions (just to explain, at CERN the alternate data streams are often precompiled caches or index files of the main file's contents, and can easily in the TB range) 4) Support for sparse data (i.e. SEEK_HOLE and SEEK_DATA) 5) More than one implementation available AFAIK Solaris, Nexenta, Illumos (NFSv4, ZFS, UFS) and Windows Alternate Data Streams (CIFS, NTFS) fit these requirements. Lionel