From owner-freebsd-fs@FreeBSD.ORG Sun Feb 14 00:24:32 2010 Return-Path: Delivered-To: freebsd-fs@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 39C91106566C; Sun, 14 Feb 2010 00:24:32 +0000 (UTC) (envelope-from dan.naumov@gmail.com) Received: from mail-qy0-f191.google.com (mail-qy0-f191.google.com [209.85.221.191]) by mx1.freebsd.org (Postfix) with ESMTP id BC4918FC08; Sun, 14 Feb 2010 00:24:31 +0000 (UTC) Received: by qyk29 with SMTP id 29so2099464qyk.13 for ; Sat, 13 Feb 2010 16:24:31 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:date:message-id:subject :from:to:content-type; bh=oRECKotooxJGM0JaHRfUl3lFOKI4KV29JBjCZEo5qXM=; b=PNA5sSqq4PkFqcRWNWx/Eo1srtIeO7VCZlG7SKDR0bvdHR0/UnIBaMrah2i6lm+qOF EPOuJn9J1xWVNfGp45/Iob6tmY6/usgBFwp1st7GsntAeplcNWXkMNITdYcZ49moH/xH Tmz+MtNRZoPI/fmoe9zWEYIbnV++dmHRCqmkY= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:date:message-id:subject:from:to:content-type; b=iBnd9inRb8XLMJytqeYn5PuCh5TkhINkMSw3BkVG67gzF7ui9v3WyILRvt6sJAiC6y y17dtu2VDxZ+BYPKUPivZ5CKsTvAq5MXwXoVEQtG3OnZQHkwL9GqDyRI2ebuWPaDc//+ H5EHfJQC0Ceisznfizk6iC+ZJdelZiGwPo4H8= MIME-Version: 1.0 Received: by 10.224.95.154 with SMTP id d26mr1592063qan.108.1266107070929; Sat, 13 Feb 2010 16:24:30 -0800 (PST) Date: Sun, 14 Feb 2010 02:24:30 +0200 Message-ID: From: Dan Naumov To: freebsd-fs@freebsd.org, freebsd-questions@freebsd.org, FreeBSD-STABLE Mailing List Content-Type: text/plain; charset=ISO-8859-1 Cc: Subject: managing ZFS automatic mounts - FreeBSD deviates from Solaris? X-BeenThere: freebsd-fs@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Filesystems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 14 Feb 2010 00:24:32 -0000 Hello >From the SUN ZFS Administration Guide: http://docs.sun.com/app/docs/doc/819-5461/gaztn?a=view "If ZFS is currently managing the file system but it is currently unmounted, and the mountpoint property is changed, the file system remains unmounted." This does not seem to be the case in FreeBSD (8.0-RELEASE): ================================= zfs get mounted tank/home NAME PROPERTY VALUE SOURCE tank/home mounted no - zfs set mountpoint=/mnt/home tank/home zfs get mounted tank/home NAME PROPERTY VALUE SOURCE tank/home mounted no - ================================= This might not look like a serious issue at first, until you try doing an installation of FreeBSD from FIXIT, trying to setup multiple filesystems and their mountpoints at the very end of the installation process. For example if you set the mountpoint of your poolname/rootfs/usr to /usr as one of the finishing touches to the system installation, it will immideately mount the filesystem, instantly breaking your FIXIT environment and you cannot proceed any further. Is this a known issue and/or should I submit a PR? - Sincerely, Dan Naumov From owner-freebsd-fs@FreeBSD.ORG Sun Feb 14 00:27:01 2010 Return-Path: Delivered-To: freebsd-fs@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id DDC6710656D6; Sun, 14 Feb 2010 00:27:01 +0000 (UTC) (envelope-from dan.naumov@gmail.com) Received: from qw-out-2122.google.com (qw-out-2122.google.com [74.125.92.27]) by mx1.freebsd.org (Postfix) with ESMTP id 6D74B8FC1F; Sun, 14 Feb 2010 00:27:01 +0000 (UTC) Received: by qw-out-2122.google.com with SMTP id 8so226290qwh.7 for ; Sat, 13 Feb 2010 16:27:00 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:in-reply-to:references :date:message-id:subject:from:to:content-type :content-transfer-encoding; bh=hkLs5ojGyaJqoyTrHRxLavMOgdRXEDy0lqa7OIT+4I4=; b=fh4krHRTBGE7HSXp5U6IbTWKqmPQ02PXf51emhO0lCrxn9/9Siet9nOd/RiM9DWsYX Rui69xnWjLQ0cY8ER5W/G84cpXgodyh5RNqQu1Rmx/bQQ8fEoheMKwHJvgzjzzcr2PVd uxM6aJaTwFsmv7iyI4YX9ETK9sSedPuvvMTdE= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :content-type:content-transfer-encoding; b=qmOB+gAhtIhbi1KiJ4HLPO8q06YnJu4mUovG2lMD1dv3VoEHHFVy+4vQksFDBG612X 9qE7GzaxdyuVL+ePxfbxSP4J7v24vF9MeNJjHm/ESgB8wbqqL0xCnuqC/qN9alf9cvX2 q6tgwY+jxv/fpFg70QKJ8c5J+xZpzuqx1PEwU= MIME-Version: 1.0 Received: by 10.224.63.170 with SMTP id b42mr1595678qai.39.1266107220466; Sat, 13 Feb 2010 16:27:00 -0800 (PST) In-Reply-To: References: Date: Sun, 14 Feb 2010 02:27:00 +0200 Message-ID: From: Dan Naumov To: freebsd-fs@freebsd.org, freebsd-questions@freebsd.org, FreeBSD-STABLE Mailing List Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: Subject: Re: managing ZFS automatic mounts - FreeBSD deviates from Solaris? X-BeenThere: freebsd-fs@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Filesystems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 14 Feb 2010 00:27:02 -0000 On Sun, Feb 14, 2010 at 2:24 AM, Dan Naumov wrote: > Hello > > From the SUN ZFS Administration Guide: > http://docs.sun.com/app/docs/doc/819-5461/gaztn?a=3Dview > > "If ZFS is currently managing the file system but it is currently > unmounted, and the mountpoint property is changed, the file system > remains unmounted." > > This does not seem to be the case in FreeBSD (8.0-RELEASE): > > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D > zfs get mounted tank/home > NAME =A0 =A0 =A0 =A0 =A0 =A0PROPERTY =A0 =A0 =A0 =A0VALUE =A0 =A0 =A0 =A0= =A0 SOURCE > tank/home =A0 =A0 =A0 =A0 =A0 =A0 =A0 mounted =A0 =A0 =A0 =A0 no =A0 =A0 = =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0- > > zfs set mountpoint=3D/mnt/home tank/home > > zfs get mounted tank/home > NAME =A0 =A0 =A0 =A0 =A0 =A0PROPERTY =A0 =A0 =A0 =A0VALUE =A0 =A0 =A0 =A0= =A0 SOURCE > tank/home =A0 =A0 =A0 =A0 =A0 =A0 =A0 mounted =A0 =A0 =A0 =A0 no =A0 =A0 = =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0- > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D > > This might not look like a serious issue at first, until you try doing > an installation of FreeBSD from FIXIT, trying to setup multiple > filesystems and their mountpoints at the very end of the installation > process. For example if you set the mountpoint of your > poolname/rootfs/usr to /usr as one of the finishing touches to the > system installation, it will immideately mount the filesystem, > instantly breaking your FIXIT environment and you cannot proceed any > further. Is this a known issue and/or should I submit a PR? Oops, I managed to screw up my previous email. My point was to show that "mounted" changes to YES after changing the mountpoint property :) - Dan From owner-freebsd-fs@FreeBSD.ORG Sun Feb 14 01:05:36 2010 Return-Path: Delivered-To: freebsd-fs@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id C93981065670; Sun, 14 Feb 2010 01:05:36 +0000 (UTC) (envelope-from gleb.kurtsou@gmail.com) Received: from mail-fx0-f228.google.com (mail-fx0-f228.google.com [209.85.220.228]) by mx1.freebsd.org (Postfix) with ESMTP id C2F328FC08; Sun, 14 Feb 2010 01:05:35 +0000 (UTC) Received: by fxm28 with SMTP id 28so21715fxm.31 for ; Sat, 13 Feb 2010 17:05:34 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:date:from:to:cc:subject :message-id:references:mime-version:content-type:content-disposition :in-reply-to:user-agent; bh=r3dAXO2A9JvdobnPhW/NmJ1meoQ2QG8xRqOqw0Q4CPk=; b=CepLPdaz5yUHstP+Mvctiyml21+YMc0GJjUxCRTEWp1Yk1BcM8GpiZncFq78quu22M qhS4Oqg8XKc02EdwG0b2brnsUGg1UJleW7vFcu89tMUiekbzEoM3jTr8AZmAlXP2TQW3 Lv+rr4wtSVZKm8At/Jrzy/YUQ9tD0WQvkr/uw= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=date:from:to:cc:subject:message-id:references:mime-version :content-type:content-disposition:in-reply-to:user-agent; b=b+WM7inDPitXXqvWWbcXMzfe79nG0UYkZByxrwryUPvvvyHFONifYywAyf0StBGZrU r+phW7YsFYylSilX1IoRFNy6/fkNlxL6sSEKT2mdPr0dapglIigwhpI5rHVIZyfq3SMz mHhts+dSgpUUCNEOmbbcIs8N0LiPOCWbVf6V4= Received: by 10.223.5.207 with SMTP id 15mr1037622faw.6.1266109534835; Sat, 13 Feb 2010 17:05:34 -0800 (PST) Received: from localhost (lan-78-157-90-54.vln.skynet.lt [78.157.90.54]) by mx.google.com with ESMTPS id h2sm7924669fkh.2.2010.02.13.17.05.31 (version=TLSv1/SSLv3 cipher=RC4-MD5); Sat, 13 Feb 2010 17:05:31 -0800 (PST) Date: Sun, 14 Feb 2010 03:05:26 +0200 From: Gleb Kurtsou To: Jaakko Heinonen Message-ID: <20100214010526.GA11217@tops.skynet.lt> References: <4b473c1f1002032014y4da8c0f0xcb74c749332cced3@mail.gmail.com> <20100204205546.GA1733@garage.freebsd.pl> <20100205011226.GA2657@tops.skynet.lt> <20100210200922.GA3109@a91-153-117-195.elisa-laajakaista.fi> MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="+HP7ph2BbKc20aGI" Content-Disposition: inline In-Reply-To: <20100210200922.GA3109@a91-153-117-195.elisa-laajakaista.fi> User-Agent: Mutt/1.5.20 (2009-06-14) Cc: freebsd-fs@freebsd.org, Pawel Jakub Dawidek Subject: Re: Unable to pwd in ZFS snapshot X-BeenThere: freebsd-fs@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Filesystems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 14 Feb 2010 01:05:36 -0000 --+HP7ph2BbKc20aGI Content-Type: text/plain; charset=utf-8 Content-Disposition: inline On (10/02/2010 22:09), Jaakko Heinonen wrote: > On 2010-02-05, Gleb Kurtsou wrote: > > Comments in zfs_ctldir.c explain the inode numbering scheme under .zfs > > in detail, each snapshot node has to have unique inode number. Correct > > inode number is returned by READDIR call, but not by GETATTR for the > > same vnode. This breaks our pwd (getcwd). The patch attached adds a hack > > to VOP_GETATTR to return expected inode numbers. > > > > Also, with r197513 reverted all inode numbers are still the same, but it > > seems to work as expected. > > r196309 added a VOP_VPTOCNP(9) implementation for snapshots. However due > to changes made in r197513 zfsctl_snapshot_vptocnp() never gets called. > > There's also another problem with the hidden .zfs directory: if the > directory is not in the name cache, __getcwd() will fail. To reproduce > this set debug.vfscache sysctl to 0 before the directory enters to > cache. > > # sysctl debug.vfscache=0 > # cd /scratch/.zfs > # /bin/pwd > pwd: .: No such file or directory > > Here's a patch which tries to fix/work around these problems: > > http://people.freebsd.org/~jh/patches/zfs-ctldir-vptocnp.diff > > The patch needs more work and I have tested it only very lightly. I see no reason in implementing VPTOCNP for directories under .zfs. The problem here lies in incorrect inode numbers (inconsistency between VOP_READDIR and VOP_GETATTR). Fixing it only in kernel (__getcwd) doesn't necessarily fixes it for all cases in userland, getcwd in our libc falls back to comparing inode numbers (algorithm equivalent to default VOP_VPTOCNP implementation), besides I think midnight commander also performs something very similar with inode numbers. Fixing inode numbers would also fix pwd issues with namecache disabled. Here is what it looks like in my case (with patch from my previous email applied): /.zfs % testdir ./. 1 1 ./.. 1 3 !!! ./snapshot 2 2 /.zfs % cd snapshot /.zfs/snapshot % testdir ./. 2 2 ./.. 1 1 ./2009-12-25 205 205 ./2010-02-10 122 122 ^^^ These two are fixed by the patch. It would be 3 3 otherwise /.zfs/snapshot % cd 2009-12-25 /.zfs/snapshot/2009-12-25 % testdir ./. 3 205 !!! ./.. 3 2 !!! ./.cshrc 13102 13102 ./media 38 38 [...] /usr/bin % testdir | head ./. 85 85 ./.. 45 45 ./from 123257 123257 ./env 123223 123223 ./bzfgrep 470652 470652 ./nm 470564 470564 ./calendar 122923 122923 [...] testdir sources attached. What do you think about it? Do you by chance have OpenSolaris running to check if situation is different there? Thanks, Gleb. > > -- > Jaakko --+HP7ph2BbKc20aGI Content-Type: text/plain; charset=utf-8 Content-Disposition: attachment; filename="testdir.c.txt" #include #include #include #include #include int main(int argc, char **argv) { char *path; char buf[MAXPATHLEN]; DIR *dirp; struct dirent de_buf; struct dirent *de; struct stat st; if (argc < 2) path = "."; else path = argv[0]; dirp = opendir(path); if (dirp == NULL) err(1, "opendir"); while (1) { if (readdir_r(dirp, &de_buf, &de) != 0) err(1, "readdir"); if (de == NULL) break; snprintf(buf, sizeof(buf), "%s/%.*s", path, de->d_namlen, de->d_name); if (lstat(buf, &st) == -1) err(1, "stat: %s, buf"); printf("%-20s\t%d\t%d\t%s\n", buf, de->d_fileno, st.st_ino, (de->d_fileno != st.st_ino ? "!!!" : "")); } closedir(dirp); return (0); } --+HP7ph2BbKc20aGI-- From owner-freebsd-fs@FreeBSD.ORG Sun Feb 14 08:49:19 2010 Return-Path: Delivered-To: freebsd-fs@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id E0C9D106566C; Sun, 14 Feb 2010 08:49:19 +0000 (UTC) (envelope-from jh@FreeBSD.org) Received: from gw03.mail.saunalahti.fi (gw03.mail.saunalahti.fi [195.197.172.111]) by mx1.freebsd.org (Postfix) with ESMTP id 9F29E8FC0A; Sun, 14 Feb 2010 08:49:19 +0000 (UTC) Received: from a91-153-117-195.elisa-laajakaista.fi (a91-153-117-195.elisa-laajakaista.fi [91.153.117.195]) by gw03.mail.saunalahti.fi (Postfix) with SMTP id 555B421670A; Sun, 14 Feb 2010 10:49:14 +0200 (EET) Date: Sun, 14 Feb 2010 10:49:14 +0200 From: Jaakko Heinonen To: Gleb Kurtsou Message-ID: <20100214084913.GA974@a91-153-117-195.elisa-laajakaista.fi> References: <4b473c1f1002032014y4da8c0f0xcb74c749332cced3@mail.gmail.com> <20100204205546.GA1733@garage.freebsd.pl> <20100205011226.GA2657@tops.skynet.lt> <20100210200922.GA3109@a91-153-117-195.elisa-laajakaista.fi> <20100214010526.GA11217@tops.skynet.lt> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20100214010526.GA11217@tops.skynet.lt> User-Agent: Mutt/1.5.20 (2009-06-14) Cc: freebsd-fs@freebsd.org, Pawel Jakub Dawidek Subject: Re: Unable to pwd in ZFS snapshot X-BeenThere: freebsd-fs@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Filesystems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 14 Feb 2010 08:49:20 -0000 Hi, On 2010-02-14, Gleb Kurtsou wrote: > problem here lies in incorrect inode numbers (inconsistency between > VOP_READDIR and VOP_GETATTR). It's normal for mount points. This is problem for kernel vn_fullpath1()/vop_stdvptocnp() because ZFS clears VV_ROOT for snapshot root vnodes but I don't see this causing a problem in user space. > Fixing it only in kernel (__getcwd) doesn't necessarily fixes it for > all cases in userland, getcwd in our libc falls back to comparing > inode numbers User space getcwd() works just fine if the .zfs directory is visible (or am I missing something?). See the code in getcwd.c under comment "If it's a mount point, have to stat each element because the inode number in the directory is for the entry in the parent directory, not the inode number of the mounted file." User space getcwd() just can't work for hidden directories. > Fixing inode numbers would also fix pwd issues with namecache disabled. I don't think so. If the .zfs directory is hidden, vop_stdvptocnp() and user space getcwd() don't work. -- Jaakko From owner-freebsd-fs@FreeBSD.ORG Sun Feb 14 10:30:11 2010 Return-Path: Delivered-To: freebsd-fs@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 7E82E1065672; Sun, 14 Feb 2010 10:30:11 +0000 (UTC) (envelope-from gleb.kurtsou@gmail.com) Received: from mail-fx0-f228.google.com (mail-fx0-f228.google.com [209.85.220.228]) by mx1.freebsd.org (Postfix) with ESMTP id 52FA18FC0A; Sun, 14 Feb 2010 10:30:10 +0000 (UTC) Received: by fxm28 with SMTP id 28so227311fxm.31 for ; Sun, 14 Feb 2010 02:30:09 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:date:from:to:cc:subject :message-id:references:mime-version:content-type:content-disposition :in-reply-to:user-agent; bh=ptplsyeNpjts/lHFaipDTrnQ1zcXY0KjlEaPPQbWCD8=; b=hOrh5VXgvu5syPGg3TZ3NHIkpxfgI8h1m/yrq1G3kLzbaMGVtzeTp1dO2IiEf/zsOC jXvUxjBFecijzgSQm3O/L6u8Kn7tFURcGCm57qYFtzPj8XXsjyfrLMeJIPMwRZSNs/z4 kzlHp1ze9w+U8O+Xw2xoOhe9UkHINWZ6t+OSw= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=date:from:to:cc:subject:message-id:references:mime-version :content-type:content-disposition:in-reply-to:user-agent; b=LuK0pnPZUBoe40h0MVGPzMl/oO0qnZNLs1BfOm08+LDQoa5lzfPNuZoC7ni9Tm2045 VyGG1J0wj/z95cQ8jPVg9PUHq5rM4YQGDdpL0i2rmLqKR/7cJhoz4oe/RYw/GAPkY3iw nsVBs2L2jKzcFeuqeuxFLSyoyhoY918QfR8iU= Received: by 10.223.81.90 with SMTP id w26mr4337631fak.9.1266143409424; Sun, 14 Feb 2010 02:30:09 -0800 (PST) Received: from localhost (lan-78-157-90-54.vln.skynet.lt [78.157.90.54]) by mx.google.com with ESMTPS id 21sm8301937fks.20.2010.02.14.02.30.07 (version=TLSv1/SSLv3 cipher=RC4-MD5); Sun, 14 Feb 2010 02:30:08 -0800 (PST) Date: Sun, 14 Feb 2010 12:30:02 +0200 From: Gleb Kurtsou To: Jaakko Heinonen Message-ID: <20100214103001.GA1851@tops.skynet.lt> References: <4b473c1f1002032014y4da8c0f0xcb74c749332cced3@mail.gmail.com> <20100204205546.GA1733@garage.freebsd.pl> <20100205011226.GA2657@tops.skynet.lt> <20100210200922.GA3109@a91-153-117-195.elisa-laajakaista.fi> <20100214010526.GA11217@tops.skynet.lt> <20100214084913.GA974@a91-153-117-195.elisa-laajakaista.fi> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline In-Reply-To: <20100214084913.GA974@a91-153-117-195.elisa-laajakaista.fi> User-Agent: Mutt/1.5.20 (2009-06-14) Cc: freebsd-fs@freebsd.org, Pawel Jakub Dawidek Subject: Re: Unable to pwd in ZFS snapshot X-BeenThere: freebsd-fs@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Filesystems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 14 Feb 2010 10:30:11 -0000 On (14/02/2010 10:49), Jaakko Heinonen wrote: > > Hi, > > On 2010-02-14, Gleb Kurtsou wrote: > > problem here lies in incorrect inode numbers (inconsistency between > > VOP_READDIR and VOP_GETATTR). > > It's normal for mount points. This is problem for kernel > vn_fullpath1()/vop_stdvptocnp() because ZFS clears VV_ROOT for snapshot > root vnodes but I don't see this causing a problem in user space. > > > Fixing it only in kernel (__getcwd) doesn't necessarily fixes it for > > all cases in userland, getcwd in our libc falls back to comparing > > inode numbers > > User space getcwd() works just fine if the .zfs directory is visible (or > am I missing something?). See the code in getcwd.c under comment "If > it's a mount point, have to stat each element because the inode number > in the directory is for the entry in the parent directory, not the inode > number of the mounted file." Ah, now i see it. Sorry for extra noise. Thanks, Gleb. > User space getcwd() just can't work for hidden directories. > > > Fixing inode numbers would also fix pwd issues with namecache disabled. > > I don't think so. If the .zfs directory is hidden, vop_stdvptocnp() and > user space getcwd() don't work. > > -- > Jaakko From owner-freebsd-fs@FreeBSD.ORG Mon Feb 15 11:07:00 2010 Return-Path: Delivered-To: freebsd-fs@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 2248B1065672 for ; Mon, 15 Feb 2010 11:07:00 +0000 (UTC) (envelope-from owner-bugmaster@FreeBSD.org) Received: from freefall.freebsd.org (freefall.freebsd.org [IPv6:2001:4f8:fff6::28]) by mx1.freebsd.org (Postfix) with ESMTP id EAB438FC18 for ; Mon, 15 Feb 2010 11:06:59 +0000 (UTC) Received: from freefall.freebsd.org (localhost [127.0.0.1]) by freefall.freebsd.org (8.14.3/8.14.3) with ESMTP id o1FB6xrf070302 for ; Mon, 15 Feb 2010 11:06:59 GMT (envelope-from owner-bugmaster@FreeBSD.org) Received: (from gnats@localhost) by freefall.freebsd.org (8.14.3/8.14.3/Submit) id o1FB6xfM070300 for freebsd-fs@FreeBSD.org; Mon, 15 Feb 2010 11:06:59 GMT (envelope-from owner-bugmaster@FreeBSD.org) Date: Mon, 15 Feb 2010 11:06:59 GMT Message-Id: <201002151106.o1FB6xfM070300@freefall.freebsd.org> X-Authentication-Warning: freefall.freebsd.org: gnats set sender to owner-bugmaster@FreeBSD.org using -f From: FreeBSD bugmaster To: freebsd-fs@FreeBSD.org Cc: Subject: Current problem reports assigned to freebsd-fs@FreeBSD.org X-BeenThere: freebsd-fs@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Filesystems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 15 Feb 2010 11:07:00 -0000 Note: to view an individual PR, use: http://www.freebsd.org/cgi/query-pr.cgi?pr=(number). The following is a listing of current problems submitted by FreeBSD users. These represent problem reports covering all versions including experimental development code and obsolete releases. S Tracker Resp. Description -------------------------------------------------------------------------------- o kern/143825 fs [nfs] [panic] Kernel panic on NFS client o kern/143345 fs [ext2fs] [patch] extfs minor header cleanups to better o kern/143343 fs [zfs] bug in sunlink flag on directories o kern/143212 fs [nfs] NFSv4 client strange work ... o kern/143184 fs [zfs] [lor] zfs/bufwait LOR o kern/142924 fs [ext2fs] [patch] Small cleanup for the inode struct in o kern/142914 fs [zfs] ZFS performance degradation over time o kern/142878 fs [zfs] [vfs] lock order reversal o kern/142872 fs [zfs] ZFS ZVOL Lockmgr Deadlock o kern/142597 fs [ext2fs] ext2fs does not work on filesystems with real o kern/142594 fs [zfs] Modification time reset to 1 Jan 1970 after fsyn o kern/142558 fs [msdosfs] patch] Minor updates to fs/msdosfs headers ( o kern/142489 fs [zfs] [lor] allproc/zfs LOR o kern/142466 fs Update 7.2 -> 8.0 on Raid 1 ends with screwed raid [re o kern/142401 fs [ntfs] [patch] Minor updates to NTFS from NetBSD o kern/142306 fs [zfs] [panic] ZFS drive (from OSX Leopard) causes two o kern/142068 fs [ufs] BSD labels are got deleted spontaneously o kern/141950 fs [unionfs] [lor] ufs/unionfs/ufs Lock order reversal o kern/141897 fs [msdosfs] [panic] Kernel panic. msdofs: file name leng o kern/141718 fs [zfs] [panic] kernel panic when 'zfs rename' is used o o kern/141685 fs [zfs] zfs corruption on adaptec 5805 raid controller o kern/141463 fs [nfs] [panic] Frequent kernel panics after upgrade fro o kern/141305 fs [zfs] FreeBSD ZFS+sendfile severe performance issues ( o kern/141257 fs [gvinum] No puedo crear RAID5 por SW con gvinum o kern/141177 fs [zfs] fsync() on FIFO causes panic() on zfs o kern/141091 fs [patch] [nullfs] fix panics with DIAGNOSTIC enabled o kern/141086 fs [nfs] [panic] panic("nfs: bioread, not dir") on FreeBS o kern/141010 fs [zfs] "zfs scrub" fails when backed by files in UFS2 o kern/140888 fs [zfs] boot fail from zfs root while the pool resilveri o kern/140682 fs [netgraph] [panic] random panic in netgraph o kern/140661 fs [zfs] [patch] /boot/loader fails to work on a GPT/ZFS- o kern/140640 fs [zfs] snapshot crash o kern/140433 fs [zfs] [panic] panic while replaying ZIL after crash o kern/140134 fs [msdosfs] write and fsck destroy filesystem integrity o kern/140068 fs [smbfs] [patch] smbfs does not allow semicolon in file o kern/139725 fs [zfs] zdb(1) dumps core on i386 when examining zpool c o kern/139715 fs [zfs] vfs.numvnodes leak on busy zfs o bin/139651 fs [nfs] mount(8): read-only remount of NFS volume does n o kern/139597 fs [patch] [tmpfs] tmpfs initializes va_gen but doesn't u o kern/139564 fs [zfs] [panic] 8.0-RC1 - Fatal trap 12 at end of shutdo o kern/139407 fs [smbfs] [panic] smb mount causes system crash if remot o kern/139363 fs [nfs] diskless root nfs mount from non FreeBSD server o kern/138790 fs [zfs] ZFS ceases caching when mem demand is high o kern/138524 fs [msdosfs] disks and usb flashes/cards with Russian lab o kern/138421 fs [ufs] [patch] remove UFS label limitations o kern/138202 fs mount_msdosfs(1) see only 2Gb f kern/137037 fs [zfs] [hang] zfs rollback on root causes FreeBSD to fr o kern/136968 fs [ufs] [lor] ufs/bufwait/ufs (open) o kern/136945 fs [ufs] [lor] filedesc structure/ufs (poll) o kern/136944 fs [ffs] [lor] bufwait/snaplk (fsync) o kern/136873 fs [ntfs] Missing directories/files on NTFS volume o kern/136865 fs [nfs] [patch] NFS exports atomic and on-the-fly atomic o kern/136470 fs [nfs] Cannot mount / in read-only, over NFS o kern/135594 fs [zfs] Single dataset unresponsive with Samba o kern/135546 fs [zfs] zfs.ko module doesn't ignore zpool.cache filenam o kern/135469 fs [ufs] [panic] kernel crash on md operation in ufs_dirb o kern/135050 fs [zfs] ZFS clears/hides disk errors on reboot o kern/134491 fs [zfs] Hot spares are rather cold... o kern/133676 fs [smbfs] [panic] umount -f'ing a vnode-based memory dis o kern/133614 fs [panic] panic: ffs_truncate: read-only filesystem o kern/133174 fs [msdosfs] [patch] msdosfs must support utf-encoded int f kern/133150 fs [zfs] Page fault with ZFS on 7.1-RELEASE/amd64 while w o kern/132960 fs [ufs] [panic] panic:ffs_blkfree: freeing free frag o kern/132397 fs reboot causes filesystem corruption (failure to sync b o kern/132331 fs [ufs] [lor] LOR ufs and syncer o kern/132237 fs [msdosfs] msdosfs has problems to read MSDOS Floppy o kern/132145 fs [panic] File System Hard Crashes o kern/131995 fs [nfs] Failure to mount NFSv4 server o kern/131441 fs [unionfs] [nullfs] unionfs and/or nullfs not combineab o kern/131360 fs [nfs] poor scaling behavior of the NFS server under lo o kern/131342 fs [nfs] mounting/unmounting of disks causes NFS to fail o bin/131341 fs makefs: error "Bad file descriptor" on the mount poin o kern/130979 fs [smbfs] [panic] boot/kernel/smbfs.ko o kern/130920 fs [msdosfs] cp(1) takes 100% CPU time while copying file o kern/130229 fs [iconv] usermount fails on fs that need iconv o kern/130210 fs [nullfs] Error by check nullfs o kern/129760 fs [nfs] after 'umount -f' of a stale NFS share FreeBSD l o kern/129488 fs [smbfs] Kernel "bug" when using smbfs in smbfs_smb.c: o kern/129231 fs [ufs] [patch] New UFS mount (norandom) option - mostly o kern/129152 fs [panic] non-userfriendly panic when trying to mount(8) o kern/129059 fs [zfs] [patch] ZFS bootloader whitelistable via WITHOUT f kern/128829 fs smbd(8) causes periodic panic on 7-RELEASE o kern/127420 fs [gjournal] [panic] Journal overflow on gmirrored gjour o kern/127029 fs [panic] mount(8): trying to mount a write protected zi o kern/126287 fs [ufs] [panic] Kernel panics while mounting an UFS file s kern/125738 fs [zfs] [request] SHA256 acceleration in ZFS p kern/124621 fs [ext3] [patch] Cannot mount ext2fs partition f bin/124424 fs [zfs] zfs(8): zfs list -r shows strange snapshots' siz o kern/123939 fs [msdosfs] corrupts new files o kern/122380 fs [ffs] ffs_valloc:dup alloc (Soekris 4801/7.0/USB Flash o bin/122172 fs [fs]: amd(8) automount daemon dies on 6.3-STABLE i386, o bin/121898 fs [nullfs] pwd(1)/getcwd(2) fails with Permission denied o bin/121779 fs [ufs] snapinfo(8) (and related tools?) only work for t o bin/121366 fs [zfs] [patch] Automatic disk scrubbing from periodic(8 o bin/121072 fs [smbfs] mount_smbfs(8) cannot normally convert the cha f kern/120991 fs [panic] [fs] [snapshot] System crashes when manipulati o kern/120483 fs [ntfs] [patch] NTFS filesystem locking changes o kern/120482 fs [ntfs] [patch] Sync style changes between NetBSD and F f kern/119735 fs [zfs] geli + ZFS + samba starting on boot panics 7.0-B o kern/118912 fs [2tb] disk sizing/geometry problem with large array o kern/118713 fs [minidump] [patch] Display media size required for a k o bin/118249 fs mv(1): moving a directory changes its mtime o kern/118107 fs [ntfs] [panic] Kernel panic when accessing a file at N o bin/117315 fs [smbfs] mount_smbfs(8) and related options can't mount o kern/117314 fs [ntfs] Long-filename only NTFS fs'es cause kernel pani o kern/117158 fs [zfs] zpool scrub causes panic if geli vdevs detach on o bin/116980 fs [msdosfs] [patch] mount_msdosfs(8) resets some flags f o kern/116913 fs [ffs] [panic] ffs_blkfree: freeing free block p kern/116608 fs [msdosfs] [patch] msdosfs fails to check mount options o kern/116583 fs [ffs] [hang] System freezes for short time when using o kern/116170 fs [panic] Kernel panic when mounting /tmp o kern/115645 fs [snapshots] [panic] lockmgr: thread 0xc4c00d80, not ex o bin/115361 fs [zfs] mount(8) gets into a state where it won't set/un o kern/114955 fs [cd9660] [patch] [request] support for mask,dirmask,ui o kern/114847 fs [ntfs] [patch] [request] dirmask support for NTFS ala o kern/114676 fs [ufs] snapshot creation panics: snapacct_ufs2: bad blo o bin/114468 fs [patch] [request] add -d option to umount(8) to detach o kern/113852 fs [smbfs] smbfs does not properly implement DFS referral o bin/113838 fs [patch] [request] mount(8): add support for relative p o bin/113049 fs [patch] [request] make quot(8) use getopt(3) and show o kern/112658 fs [smbfs] [patch] smbfs and caching problems (resolves b o kern/111843 fs [msdosfs] Long Names of files are incorrectly created o kern/111782 fs [ufs] dump(8) fails horribly for large filesystems s bin/111146 fs [2tb] fsck(8) fails on 6T filesystem o kern/109024 fs [msdosfs] mount_msdosfs: msdosfs_iconv: Operation not o kern/109010 fs [msdosfs] can't mv directory within fat32 file system o bin/107829 fs [2TB] fdisk(8): invalid boundary checking in fdisk / w o kern/106030 fs [ufs] [panic] panic in ufs from geom when a dead disk o kern/104406 fs [ufs] Processes get stuck in "ufs" state under persist o kern/104133 fs [ext2fs] EXT2FS module corrupts EXT2/3 filesystems o kern/103035 fs [ntfs] Directories in NTFS mounted disc images appear o kern/101324 fs [smbfs] smbfs sometimes not case sensitive when it's s o kern/99290 fs [ntfs] mount_ntfs ignorant of cluster sizes o kern/97377 fs [ntfs] [patch] syntax cleanup for ntfs_ihash.c o kern/95222 fs [iso9660] File sections on ISO9660 level 3 CDs ignored o kern/94849 fs [ufs] rename on UFS filesystem is not atomic o kern/94769 fs [ufs] Multiple file deletions on multi-snapshotted fil o kern/94733 fs [smbfs] smbfs may cause double unlock o kern/93942 fs [vfs] [patch] panic: ufs_dirbad: bad dir (patch from D o kern/92272 fs [ffs] [hang] Filling a filesystem while creating a sna f kern/91568 fs [ufs] [panic] writing to UFS/softupdates DVD media in o kern/91134 fs [smbfs] [patch] Preserve access and modification time a kern/90815 fs [smbfs] [patch] SMBFS with character conversions somet o kern/88657 fs [smbfs] windows client hang when browsing a samba shar o kern/88266 fs [smbfs] smbfs does not implement UIO_NOCOPY and sendfi o kern/87859 fs [smbfs] System reboot while umount smbfs. o kern/86587 fs [msdosfs] rm -r /PATH fails with lots of small files o kern/85326 fs [smbfs] [panic] saving a file via samba to an overquot o kern/84589 fs [2TB] 5.4-STABLE unresponsive during background fsck 2 o kern/80088 fs [smbfs] Incorrect file time setting on NTFS mounted vi o kern/73484 fs [ntfs] Kernel panic when doing `ls` from the client si o bin/73019 fs [ufs] fsck_ufs(8) cannot alloc 607016868 bytes for ino o kern/71774 fs [ntfs] NTFS cannot "see" files on a WinXP filesystem o kern/68978 fs [panic] [ufs] crashes with failing hard disk, loose po o kern/65920 fs [nwfs] Mounted Netware filesystem behaves strange o kern/65901 fs [smbfs] [patch] smbfs fails fsx write/truncate-down/tr o kern/61503 fs [smbfs] mount_smbfs does not work as non-root o kern/55617 fs [smbfs] Accessing an nsmb-mounted drive via a smb expo o kern/51685 fs [hang] Unbounded inode allocation causes kernel to loc o kern/51583 fs [nullfs] [patch] allow to work with devices and socket o kern/36566 fs [smbfs] System reboot with dead smb mount and umount o kern/18874 fs [2TB] 32bit NFS servers export wrong negative values t 162 problems total. From owner-freebsd-fs@FreeBSD.ORG Mon Feb 15 11:32:20 2010 Return-Path: Delivered-To: freebsd-fs@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 47CED106566B for ; Mon, 15 Feb 2010 11:32:20 +0000 (UTC) (envelope-from ndenev@gmail.com) Received: from mail-fx0-f226.google.com (mail-fx0-f226.google.com [209.85.220.226]) by mx1.freebsd.org (Postfix) with ESMTP id CD90B8FC15 for ; Mon, 15 Feb 2010 11:32:19 +0000 (UTC) Received: by fxm26 with SMTP id 26so4860046fxm.13 for ; Mon, 15 Feb 2010 03:32:18 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:from:content-type :content-transfer-encoding:subject:date:message-id:to:mime-version :x-mailer; bh=iu9VRepAWUgIW3/krTVY2EohGMFQw/NfLna7DgMeUGE=; b=D3smZbHHOpfTOv63pjBxVau/VMXatnL/n7MzDXI1Xsl6B0IRtyvxjMY/dPpeszyxVa B9zSt4VmYfG09g6CJkVTkapPlx7xO8G6GvN5NxH3dm0IEOd6jEocj35wcWgNa7kFYjQ4 8x3j4gwwr+hsK3QvI/Lh58NqAPGjACYefWd6M= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=from:content-type:content-transfer-encoding:subject:date:message-id :to:mime-version:x-mailer; b=w+iZz1EwT6KQ6+Uh0b6DEMd+7HZS5eqZQlR2cyTR9DNd8EXCh6IAp7f3NLQbsoMEfy 92aAUZG7k3iUsQmZdUloKYN3D0fRHOI/R4D2POHZABrEx5ROrTuVZ3ftV0hB6Ke0GNJM aXgnkpWGkD1aiCdhYNPG2O7j4Nsx9g1GZCPQA= Received: by 10.102.214.19 with SMTP id m19mr3692701mug.96.1266233538368; Mon, 15 Feb 2010 03:32:18 -0800 (PST) Received: from ?10.32.23.105? ([195.34.111.178]) by mx.google.com with ESMTPS id u26sm32892656mug.7.2010.02.15.03.32.17 (version=TLSv1/SSLv3 cipher=RC4-MD5); Mon, 15 Feb 2010 03:32:17 -0800 (PST) From: Nikolay Denev Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Date: Mon, 15 Feb 2010 13:32:15 +0200 Message-Id: <9A0A9D7E-EF1C-4894-B220-13EC3500FEBC@gmail.com> To: freebsd-fs@freebsd.org Mime-Version: 1.0 (Apple Message framework v1077) X-Mailer: Apple Mail (2.1077) Subject: Can the various ZFS tunables be converted to sysctls? X-BeenThere: freebsd-fs@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Filesystems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 15 Feb 2010 11:32:20 -0000 Hello, During some periods of extensive ZFS testing and tuning I began to = wonder is it possible to make at least some of the ZFS tunables sysctls so that they can be = modified on a runing system? I don't know if that's possible even on Solaris, so maybe the code = assumes that they are not to be changed on a running system, but anyways seems like a useful thing that = would save a tons of reboots globally :) Regards, Niki Denev From owner-freebsd-fs@FreeBSD.ORG Mon Feb 15 18:07:55 2010 Return-Path: Delivered-To: freebsd-fs@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 77AF8106566C; Mon, 15 Feb 2010 18:07:55 +0000 (UTC) (envelope-from mattjreimer@gmail.com) Received: from mail-gx0-f218.google.com (mail-gx0-f218.google.com [209.85.217.218]) by mx1.freebsd.org (Postfix) with ESMTP id 0A9A08FC21; Mon, 15 Feb 2010 18:07:54 +0000 (UTC) Received: by gxk10 with SMTP id 10so4197598gxk.3 for ; Mon, 15 Feb 2010 10:07:54 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:in-reply-to:references :date:message-id:subject:from:to:cc:content-type; bh=NGYzNaasNYljdlL3wgw7cL1c/RKQDfP5pILOr2jbuOc=; b=rRrmZEeYDsaqFbdMxRDGsi5ZEsnoGMP3kQplajTXfDtClfukuAZILbLov627vYCs6s cjK34rufBD5LW4SbaBHk/zN7/0ZmIi2oYDn+2Gms1Jwkmw324IV8RiMx4cHsZLLcSNrJ 1Oaw96NghLzMM4B1wtbOJO93A5liakxcQiy5s= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; b=nOvjWnn5Z7dBl7nP3D3Sk1lWVj3fp7rdvrHYBT8pWInicaAwEp5NAHF4py36PmI+Jf Z1H15W97RMCv+ltmriCOEXfWK2tLA1th6IFWqkHkZ2lQqXAxwFXaSwDYOkN3bgYN/mCT uGAkh1oW9mv1a1OAV5HhfzsZHaSogZgvL8XrA= MIME-Version: 1.0 Received: by 10.150.67.13 with SMTP id p13mr6644871yba.15.1266257274199; Mon, 15 Feb 2010 10:07:54 -0800 (PST) In-Reply-To: References: Date: Mon, 15 Feb 2010 10:07:54 -0800 Message-ID: From: Matt Reimer To: Dan Naumov Content-Type: text/plain; charset=ISO-8859-1 X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Cc: freebsd-fs@freebsd.org, FreeBSD-STABLE Mailing List , freebsd-questions@freebsd.org Subject: Re: booting off a ZFS pool consisting of multiple striped mirror vdevs X-BeenThere: freebsd-fs@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Filesystems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 15 Feb 2010 18:07:55 -0000 On Sat, Feb 13, 2010 at 12:04 PM, Dan Naumov wrote: > Hello > > I have succesfully tested and used a "full ZFS install" of FreeBSD 8.0 > on both single disk and mirror disk configurations using both MBR and > GPT partitioning. AFAIK, with the more recent -CURRENT and -STABLE it > is also possible to boot off a root filesystem located on raidz/raidz2 > pools. But what about booting off pools consisting of multiple striped > mirror or raidz vdevs? Like this: > > Assume each disk looks like a half of a traditional ZFS mirror root > configuration using GPT > > 1: freebsd-boot > 2: freebsd-swap > 3: freebsd-zfs > > |disk1+disk2| + |disk3+disk4| + |disk5+disk6| > > My logic tells me that while booting off any of the 6 disks, boot0 and > boot1 stage should obviously work fine, but what about the boot2 > stage? Can it properly handle booting off a root filesystem thats > striped across 3 mirror vdevs or is booting off a single mirror vdev > the best that one can do right now? > > I don't know, but I plan to test that scenario in a few days. Matt From owner-freebsd-fs@FreeBSD.ORG Mon Feb 15 18:26:00 2010 Return-Path: Delivered-To: freebsd-fs@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 67D76106568D; Mon, 15 Feb 2010 18:25:59 +0000 (UTC) (envelope-from rnoland@FreeBSD.org) Received: from gizmo.2hip.net (gizmo.2hip.net [64.74.207.195]) by mx1.freebsd.org (Postfix) with ESMTP id 0AC9F8FC1C; Mon, 15 Feb 2010 18:25:58 +0000 (UTC) Received: from [192.168.1.4] (adsl-241-172-37.bna.bellsouth.net [74.241.172.37]) (authenticated bits=0) by gizmo.2hip.net (8.14.3/8.14.3) with ESMTP id o1FIPreD048453 (version=TLSv1/SSLv3 cipher=DHE-RSA-CAMELLIA256-SHA bits=256 verify=NO); Mon, 15 Feb 2010 13:25:55 -0500 (EST) (envelope-from rnoland@FreeBSD.org) From: Robert Noland To: Matt Reimer In-Reply-To: References: Content-Type: text/plain Organization: FreeBSD Date: Mon, 15 Feb 2010 12:25:48 -0600 Message-Id: <1266258348.11131.21.camel@balrog.2hip.net> Mime-Version: 1.0 X-Mailer: Evolution 2.26.3 FreeBSD GNOME Team Port Content-Transfer-Encoding: 7bit X-Spam-Status: No, score=-0.4 required=5.0 tests=AWL,BAYES_00, FH_DATE_PAST_20XX,RCVD_IN_PBL,RDNS_DYNAMIC,SPF_SOFTFAIL autolearn=no version=3.2.5 X-Spam-Checker-Version: SpamAssassin 3.2.5 (2008-06-10) on gizmo.2hip.net Cc: freebsd-fs@freebsd.org, FreeBSD-STABLE Mailing List , Dan Naumov , freebsd-questions@freebsd.org Subject: Re: booting off a ZFS pool consisting of multiple striped mirror vdevs X-BeenThere: freebsd-fs@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Filesystems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 15 Feb 2010 18:26:00 -0000 On Mon, 2010-02-15 at 10:07 -0800, Matt Reimer wrote: > On Sat, Feb 13, 2010 at 12:04 PM, Dan Naumov wrote: > > > Hello > > > > I have succesfully tested and used a "full ZFS install" of FreeBSD 8.0 > > on both single disk and mirror disk configurations using both MBR and > > GPT partitioning. AFAIK, with the more recent -CURRENT and -STABLE it > > is also possible to boot off a root filesystem located on raidz/raidz2 > > pools. But what about booting off pools consisting of multiple striped > > mirror or raidz vdevs? Like this: > > > > Assume each disk looks like a half of a traditional ZFS mirror root > > configuration using GPT > > > > 1: freebsd-boot > > 2: freebsd-swap > > 3: freebsd-zfs > > > > |disk1+disk2| + |disk3+disk4| + |disk5+disk6| > > > > My logic tells me that while booting off any of the 6 disks, boot0 and > > boot1 stage should obviously work fine, but what about the boot2 > > stage? Can it properly handle booting off a root filesystem thats > > striped across 3 mirror vdevs or is booting off a single mirror vdev > > the best that one can do right now? > > > > > I don't know, but I plan to test that scenario in a few days. It *should* work... I made changes a while back that allow for multiple vdevs to attach to the root. In this case you should have 3 mirror vdevs attached to the root, so as long as the BIOS can enumerate all of the drives, we should find all of the vdevs and build the tree correctly. It should be simple enough to test in qemu, except that the BIOS in qemu is a little broken and might not id all of the drives. robert. > Matt > _______________________________________________ > freebsd-stable@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-stable > To unsubscribe, send any mail to "freebsd-stable-unsubscribe@freebsd.org" -- Robert Noland FreeBSD From owner-freebsd-fs@FreeBSD.ORG Mon Feb 15 21:19:59 2010 Return-Path: Delivered-To: freebsd-fs@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id E18E6106566C for ; Mon, 15 Feb 2010 21:19:59 +0000 (UTC) (envelope-from kpielorz_lst@tdx.co.uk) Received: from mail.tdx.com (mail.tdx.com [62.13.128.18]) by mx1.freebsd.org (Postfix) with ESMTP id 611768FC12 for ; Mon, 15 Feb 2010 21:19:58 +0000 (UTC) Received: from Octa64 (octa64.tdx.co.uk [62.13.130.232]) (authenticated bits=0) by mail.tdx.com (8.14.3/8.14.3/Kp) with ESMTP id o1FL6q3D074569 for ; Mon, 15 Feb 2010 21:06:52 GMT Date: Mon, 15 Feb 2010 21:07:03 +0000 From: Karl Pielorz To: freebsd-fs@freebsd.org Message-ID: X-Mailer: Mulberry/4.0.8 (Win32) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline Subject: ZFS on FreeBSD / inodes / df -i - Am I running out? X-BeenThere: freebsd-fs@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Filesystems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 15 Feb 2010 21:20:00 -0000 Hi All, I'm running ZFS under FreeBSD 7.2-STABLE. I've noticed on a couple of machines, "df -i" seems to indicate I'm starting to run out of inodes, e.g. " Filesystem 1K-blocks Used Avail Capacity iused ifree %iused Mounted on vol/imap 34144512 23131136 11013376 68% 1723522 86042 95% /vol/imap " I know ZFS doesn't have 'inodes' (I think it has znodes?) - but do I need to be concerned that 'df -i' shows me down to 5% of what it thinks are 'inodes' are available? Thanks, -Karl From owner-freebsd-fs@FreeBSD.ORG Tue Feb 16 11:18:23 2010 Return-Path: Delivered-To: freebsd-fs@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id A85E5106568B; Tue, 16 Feb 2010 11:18:23 +0000 (UTC) (envelope-from dan.naumov@gmail.com) Received: from mail-yw0-f182.google.com (mail-yw0-f182.google.com [209.85.211.182]) by mx1.freebsd.org (Postfix) with ESMTP id 50A068FC13; Tue, 16 Feb 2010 11:18:23 +0000 (UTC) Received: by ywh12 with SMTP id 12so2860305ywh.7 for ; Tue, 16 Feb 2010 03:18:22 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:in-reply-to:references :date:message-id:subject:from:to:content-type :content-transfer-encoding; bh=HJRsX6YNug0zQ8xRnv055At3RmJxvvQuJZDNVYMoHu8=; b=pn3tDtjCCaSx6auYzrXXrY13rc2znq3ehXIo4R5cWXwPZJovyRI/Ft0HwfNO/ltMPL /SmXyYZRIYu3vE+85lLM3AcvDamMUXHWaKJ97iZ4Pb5c1FQidMCGRKPDlZ1q/FIqDW4p Jvopf91+y8iflMK6+4tYosdanp6y7uMjdsatU= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :content-type:content-transfer-encoding; b=fD/e5xAncDLBVALPuTRqPvSk8ocQoGj0ea+zMHNyQAgMaDzW6C7k3BVmculwUNMx9Q M6NTSTK6nKAsOMVokrDZnV91PC9Coc0hkeCLk86cEKk6PXN8UHeN+nAqKZaFjspbNBCl xHiSeiUTc0D35uXCedtHwmfgEskHrAsqiE6tg= MIME-Version: 1.0 Received: by 10.101.145.27 with SMTP id x27mr4143199ann.77.1266319102559; Tue, 16 Feb 2010 03:18:22 -0800 (PST) In-Reply-To: References: Date: Tue, 16 Feb 2010 13:18:22 +0200 Message-ID: From: Dan Naumov To: freebsd-questions@freebsd.org, freebsd-fs@freebsd.org Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: Subject: RE: booting off a ZFS pool consisting of multiple striped mirror vdevs X-BeenThere: freebsd-fs@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Filesystems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 16 Feb 2010 11:18:23 -0000 > I don't know, but I plan to test that scenario in a few days. > > Matt Please share the results when you're done, I am really curious :) > It *should* work... I made changes a while back that allow for multiple > vdevs to attach to the root. =A0In this case you should have 3 mirror > vdevs attached to the root, so as long as the BIOS can enumerate all of > the drives, we should find all of the vdevs and build the tree > correctly. =A0It should be simple enough to test in qemu, except that the > BIOS in qemu is a little broken and might not id all of the drives. > > robert. If booting of a stripe of 3 mirrors should work assuming no BIOS bugs, can you explain why is booting off simple stripes (of any number of disks) currently unsupported? I haven't tested that myself, but everywhere I look seems to indicate that booting off a simple stripe doesn't work or is that "everywhere" also out of date after your changes? :) - Sincerely, Dan Naumov From owner-freebsd-fs@FreeBSD.ORG Tue Feb 16 17:16:07 2010 Return-Path: Delivered-To: freebsd-fs@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 8DA461065672; Tue, 16 Feb 2010 17:16:07 +0000 (UTC) (envelope-from jh@FreeBSD.org) Received: from gw01.mail.saunalahti.fi (gw01.mail.saunalahti.fi [195.197.172.115]) by mx1.freebsd.org (Postfix) with ESMTP id 4C4898FC13; Tue, 16 Feb 2010 17:16:07 +0000 (UTC) Received: from a91-153-117-195.elisa-laajakaista.fi (a91-153-117-195.elisa-laajakaista.fi [91.153.117.195]) by gw01.mail.saunalahti.fi (Postfix) with SMTP id 436D415193B; Tue, 16 Feb 2010 19:16:02 +0200 (EET) Date: Tue, 16 Feb 2010 19:16:01 +0200 From: Jaakko Heinonen To: Gleb Kurtsou Message-ID: <20100216171601.GA3640@a91-153-117-195.elisa-laajakaista.fi> References: <4b473c1f1002032014y4da8c0f0xcb74c749332cced3@mail.gmail.com> <20100204205546.GA1733@garage.freebsd.pl> <20100205011226.GA2657@tops.skynet.lt> <20100210200922.GA3109@a91-153-117-195.elisa-laajakaista.fi> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20100210200922.GA3109@a91-153-117-195.elisa-laajakaista.fi> User-Agent: Mutt/1.5.20 (2009-06-14) Cc: freebsd-fs@freebsd.org, Pawel Jakub Dawidek Subject: Re: Unable to pwd in ZFS snapshot X-BeenThere: freebsd-fs@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Filesystems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 16 Feb 2010 17:16:07 -0000 On 2010-02-10, Jaakko Heinonen wrote: > http://people.freebsd.org/~jh/patches/zfs-ctldir-vptocnp.diff > > The patch needs more work and I have tested it only very lightly. I have updated the patch at the URL above. Now it passes some testing without deadlocking. :) -- Jaakko From owner-freebsd-fs@FreeBSD.ORG Tue Feb 16 21:10:12 2010 Return-Path: Delivered-To: freebsd-fs@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id EA1B010656A5 for ; Tue, 16 Feb 2010 21:10:12 +0000 (UTC) (envelope-from cvs-src@yandex.ru) Received: from forward13.mail.yandex.net (forward13.mail.yandex.net [95.108.130.120]) by mx1.freebsd.org (Postfix) with ESMTP id 722D78FC0A for ; Tue, 16 Feb 2010 21:10:12 +0000 (UTC) Received: from smtp14.mail.yandex.net (smtp14.mail.yandex.net [95.108.131.192]) by forward13.mail.yandex.net (Yandex) with ESMTP id 08458A780F0 for ; Tue, 16 Feb 2010 23:50:19 +0300 (MSK) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yandex.ru; s=mail; t=1266353419; bh=JqvNnPZf95k9xlUK8uR7XKba7uBXqVx8xT0eENnrrz4=; h=Message-ID:Date:From:MIME-Version:To:Subject:Content-Type: Content-Transfer-Encoding; b=LMS2pfSarhtoV7Awm+sjzHCP9bHZaawsz+/TksTYZboqD/qltxKAaqSG8IERqZFDK Oy9EnRt6PhvD95XOYnszhknpdnWnRe9zywR0Na0IZ2mU/z0brthU1EZ1Bpzi8sgSxx 3u/NLUhnyVNRX8GDhUUP81dWaOi8+btHzzdz8dJg= Received: from smeshariki2.local (unknown [77.66.250.137]) by smtp14.mail.yandex.net (Yandex) with ESMTPSA id D77BF68041 for ; Tue, 16 Feb 2010 23:50:18 +0300 (MSK) Message-ID: <4B7B04F6.3010302@yandex.ru> Date: Tue, 16 Feb 2010 23:49:58 +0300 From: Ruslan Mahmatkhanov User-Agent: Mozilla/5.0 (X11; U; FreeBSD i386; ru-RU; rv:1.9.1.7) Gecko/20100211 Thunderbird/3.0.1 MIME-Version: 1.0 To: freebsd-fs@freebsd.org Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Yandex-TimeMark: 1266353419 X-Yandex-Spam: 1 X-Yandex-Front: smtp14.mail.yandex.net Subject: Any plans to sync udf with NetBSD X-BeenThere: freebsd-fs@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Filesystems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 16 Feb 2010 21:10:13 -0000 Hello! Does anybody in FreeBSD community is working on syncing udf code with NetBSD implementation? They now have v2.60 spec support, and FreeBSD can't yet read v2.0 discs, burned in vista. I know about udfclient port, but it is always great to have it in native. I can't code myself but i can help in testing ;) Thanks. From owner-freebsd-fs@FreeBSD.ORG Wed Feb 17 00:26:53 2010 Return-Path: Delivered-To: freebsd-fs@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 0F31A1065672 for ; Wed, 17 Feb 2010 00:26:53 +0000 (UTC) (envelope-from morganw@chemikals.org) Received: from warped.bluecherry.net (unknown [IPv6:2001:440:eeee:fffb::2]) by mx1.freebsd.org (Postfix) with ESMTP id B0F238FC16 for ; Wed, 17 Feb 2010 00:26:52 +0000 (UTC) Received: from volatile.chemikals.org (adsl-67-252-5.shv.bellsouth.net [98.67.252.5]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by warped.bluecherry.net (Postfix) with ESMTPSA id AC68F98F3802; Tue, 16 Feb 2010 18:26:51 -0600 (CST) Received: from localhost (morganw@localhost [127.0.0.1]) by volatile.chemikals.org (8.14.3/8.14.3) with ESMTP id o1H0QiLr093980; Tue, 16 Feb 2010 18:26:45 -0600 (CST) (envelope-from morganw@chemikals.org) Date: Tue, 16 Feb 2010 18:26:44 -0600 (CST) From: Wes Morgan X-X-Sender: morganw@volatile To: Ruslan Mahmatkhanov In-Reply-To: <4B7B04F6.3010302@yandex.ru> Message-ID: References: <4B7B04F6.3010302@yandex.ru> User-Agent: Alpine 2.00 (BSF 1167 2008-08-23) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Virus-Scanned: clamav-milter 0.95.3 at warped X-Virus-Status: Clean Cc: freebsd-fs@freebsd.org Subject: Re: Any plans to sync udf with NetBSD X-BeenThere: freebsd-fs@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Filesystems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 17 Feb 2010 00:26:53 -0000 On Tue, 16 Feb 2010, Ruslan Mahmatkhanov wrote: > Hello! > > Does anybody in FreeBSD community is working on syncing udf code with NetBSD > implementation? They now have v2.60 spec support, and FreeBSD can't yet read > v2.0 discs, burned in vista. > > I know about udfclient port, but it is always great to have it in native. I > can't code myself but i can help in testing ;) I second the motion. This is a necessary step for blu-ray support, as well. How close is the netbsd filesystem layer to ours? From owner-freebsd-fs@FreeBSD.ORG Wed Feb 17 17:13:30 2010 Return-Path: Delivered-To: FreeBSD-FS@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id B807D106568B for ; Wed, 17 Feb 2010 17:13:30 +0000 (UTC) (envelope-from jhellenthal@gmail.com) Received: from mail-vw0-f54.google.com (mail-vw0-f54.google.com [209.85.212.54]) by mx1.freebsd.org (Postfix) with ESMTP id 5D9038FC0C for ; Wed, 17 Feb 2010 17:13:30 +0000 (UTC) Received: by vws14 with SMTP id 14so207966vws.13 for ; Wed, 17 Feb 2010 09:13:29 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:sender:date:from:to:cc :subject:in-reply-to:message-id:references:user-agent :x-openpgp-key-id:x-openpgp-key-fingerprint:mime-version :content-type; bh=UTEDLfSiVZ0KABYlTVrDK8SBFWC3dEeHheAMGypL5RY=; b=jgS4v0srNkou6VwM/ysjOtw5arCsamVllK0tLJW0nfPZuVHtxgyoDGa4uDB7JSOt2O lW10stpNYhfXsw62XpVreDLY0N3ct/0wGNlOavmEgabKwl9GwiuQ7uwMQmKfJbgEUVvl Ku09TRErx7LeOuccZaYCPTZdnWzGB49HICums= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=sender:date:from:to:cc:subject:in-reply-to:message-id:references :user-agent:x-openpgp-key-id:x-openpgp-key-fingerprint:mime-version :content-type; b=jrkCwGxQWllIeuHtFCcpJlCBN5QZ7l97K02IMCO5FeNBSNFC10yKMVXLo9SlAx+8Gk C11tzomgdASbfg5gYjsAujPQpJmRqyhuTQCOfznD1SK3w81HEqlR4TtzveuFsIYtCgRL BsIHoK6i4Y/gsdVyKrR2CGGM5S5ly1f8KD/cQ= Received: by 10.220.123.92 with SMTP id o28mr2077237vcr.116.1266426809441; Wed, 17 Feb 2010 09:13:29 -0800 (PST) Received: from ppp-22.107.dialinfree.com (ppp-22.107.dialinfree.com [209.172.22.107]) by mx.google.com with ESMTPS id 25sm10735773vws.21.2010.02.17.09.13.24 (version=TLSv1/SSLv3 cipher=RC4-MD5); Wed, 17 Feb 2010 09:13:27 -0800 (PST) Sender: "J. Hellenthal" Date: Wed, 17 Feb 2010 12:13:11 -0500 From: jhell To: Alexander Leidinger In-Reply-To: <20100217153530.10865szil9xmgfwg@webmail.leidinger.net> Message-ID: References: <20100215090756.GA54764@icarus.home.lan> <20100215105000.101326yj01j0f64g@webmail.leidinger.net> <20100215122744.GA57382@icarus.home.lan> <20100215161105.14071eiflhc9le68@webmail.leidinger.net> <4B79BA9C.3020402@quip.cz> <20100217153530.10865szil9xmgfwg@webmail.leidinger.net> User-Agent: Alpine 2.00 (BSF 1167 2008-08-23) X-OpenPGP-Key-Id: 0x89D8547E X-OpenPGP-Key-Fingerprint: 85EF E26B 07BB 3777 76BE B12A 9057 8789 89D8 547E MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Cc: FreeBSD Filesystems Subject: [arc_summary.pl/arcstat.pl] Adjustments, PR & Requests X-BeenThere: freebsd-fs@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Filesystems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 17 Feb 2010 17:13:30 -0000 On Wed, 17 Feb 2010 09:35, Alexander@ wrote: > Quoting jhell (from Wed, 17 Feb 2010 06:31:24 -0500): > >> Due to the nature of this thread and its current list involvement I am >> going to be starting a new thread in freebsd-filesystems@ just for >> arc_summary.pl tomorrow night with the subject below. >> >> [arc_summary.pl] Adjustments, PR & Requests > > Good idea. > > I have not looked at the perl code, but I wonder if it would be possbile to > have one perl script which works on FreeBSD and Solaris. This way people do > not need to reinvent the wheel. > I had that on the back of my mind during a few changes to the script that are FreeBSD specific. Fortunately the actual changes made to this could be wrapped up by a minimal amount of if statements that could separate the FreeBSD side from the original Solaris output restoring common functionality to both sides. As for arcstat.pl I am not sure at this point what it would take to convert that to something that would run on both or even if the modifications to arcstat.pl that are FreeBSD specific would run on a Solaris box as-is. Ill give all this some testing over the next week and see what I come up with. If anyone wants to submit some patches to the two adjustments discussed above I would love to include them or at least build upon the ideas. > Regarding the arcstats.pl I will have a look later at adding the link to the > wiki, maybe tomorrow. I just had a dental OP 3 hours ago, so I just quickly > browse through my mails while holding a bag of ice to one side of my face... > Thanks. Hope you feel better. I hate having dental work done. Though I hadn't had much I did have 5 teeth pulled at the same time once and ouch! is about what sums it up. > Bye, > Alexander. > > Regards, -- jhell From owner-freebsd-fs@FreeBSD.ORG Thu Feb 18 12:37:03 2010 Return-Path: Delivered-To: freebsd-fs@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id D73EB106566C for ; Thu, 18 Feb 2010 12:37:03 +0000 (UTC) (envelope-from alexz@visp.ru) Received: from mail.visp.ru (srv1.visp.ru [91.215.204.2]) by mx1.freebsd.org (Postfix) with ESMTP id 8A0A48FC14 for ; Thu, 18 Feb 2010 12:37:03 +0000 (UTC) Received: from 91-215-205-255.static.visp.ru ([91.215.205.255] helo=zagrebin) by mail.visp.ru with esmtp (Exim 4.66 (FreeBSD)) (envelope-from ) id 1Ni5cs-0003bC-7l for freebsd-fs@freebsd.org; Thu, 18 Feb 2010 15:37:02 +0300 From: "Alexander Zagrebin" To: Date: Thu, 18 Feb 2010 15:37:02 +0300 Message-ID: MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="----=_NextPart_000_01A3_01CAB0B0.375217A0" X-Mailer: Microsoft Office Outlook 11 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.5512 Thread-Index: AcqwlxHGMdgfxwsoTGybPepxOBuZww== Subject: ZFS: statfs and recordsize problem X-BeenThere: freebsd-fs@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Filesystems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 18 Feb 2010 12:37:03 -0000 This is a multi-part message in MIME format. ------=_NextPart_000_01A3_01CAB0B0.375217A0 Content-Type: text/plain; charset="koi8-r" Content-Transfer-Encoding: 7bit I have noticed, that statfs called for ZFS file systems, returns the value of FS's recordsize property in both f_bsize and f_iosize. It's a problem for some software. For example, squid uses block size of cache's file system to calculate the space occupied by file. So by default it considers that any small file uses 128KB of a cache (when default value of recordsize is used), though really this file may use 512B only. This miscalculation leads to unreasonable cleaning of a cache. IMHO the behavior of statfs have to be changed, as ZFS uses variable (up to recordsize) block sizes. It must return 512 as f_bsize and recordsize as f_iosize. One of possible solutions is the attached patch. Could somebody look it? -- Alexander Zagrebin ------=_NextPart_000_01A3_01CAB0B0.375217A0 Content-Type: application/octet-stream; name="patch-zfs_vfsops.c" Content-Transfer-Encoding: quoted-printable Content-Disposition: attachment; filename="patch-zfs_vfsops.c" --- sys/cddl/contrib/opensolaris/uts/common/fs/zfs/zfs_vfsops.c.orig = 2009-09-29 14:53:06.000000000 +0400=0A= +++ sys/cddl/contrib/opensolaris/uts/common/fs/zfs/zfs_vfsops.c = 2009-10-26 15:47:29.365783209 +0300=0A= @@ -214,7 +214,7 @@=0A= newval =3D SPA_MAXBLOCKSIZE;=0A= =0A= zfsvfs->z_max_blksz =3D newval;=0A= - zfsvfs->z_vfs->vfs_bsize =3D newval;=0A= + zfsvfs->z_vfs->mnt_stat.f_iosize =3D newval;=0A= }=0A= =0A= static void=0A= @@ -577,7 +577,8 @@=0A= if (error =3D dsl_prop_get_integer(osname, "recordsize", &recordsize,=0A= NULL))=0A= goto out;=0A= - zfsvfs->z_vfs->vfs_bsize =3D recordsize;=0A= + zfsvfs->z_vfs->vfs_bsize =3D SPA_MINBLOCKSIZE;=0A= + zfsvfs->z_vfs->mnt_stat.f_iosize =3D recordsize;=0A= =0A= vfsp->vfs_data =3D zfsvfs;=0A= vfsp->mnt_flag |=3D MNT_LOCAL;=0A= @@ -817,8 +818,8 @@=0A= * We report the fragsize as the smallest block size we support,=0A= * and we report our blocksize as the filesystem's maximum blocksize.=0A= */=0A= - statp->f_bsize =3D zfsvfs->z_vfs->vfs_bsize;=0A= - statp->f_iosize =3D zfsvfs->z_vfs->vfs_bsize;=0A= + statp->f_bsize =3D SPA_MINBLOCKSIZE;=0A= + statp->f_iosize =3D zfsvfs->z_vfs->mnt_stat.f_iosize;=0A= =0A= /*=0A= * The following report "total" blocks of various kinds in the=0A= ------=_NextPart_000_01A3_01CAB0B0.375217A0-- From owner-freebsd-fs@FreeBSD.ORG Fri Feb 19 07:42:39 2010 Return-Path: Delivered-To: freebsd-fs@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 82664106566B for ; Fri, 19 Feb 2010 07:42:39 +0000 (UTC) (envelope-from ndenev@gmail.com) Received: from fg-out-1718.google.com (fg-out-1718.google.com [72.14.220.154]) by mx1.freebsd.org (Postfix) with ESMTP id 11DEC8FC12 for ; Fri, 19 Feb 2010 07:42:38 +0000 (UTC) Received: by fg-out-1718.google.com with SMTP id 22so433025fge.13 for ; Thu, 18 Feb 2010 23:42:38 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:from:content-type :content-transfer-encoding:subject:date:message-id:to:mime-version :x-mailer; bh=VR2q7z6L7dA2n5DQe479ofbeYPDxe6/Ue2jdLwYXC7Y=; b=Ta/GF7RVBPSy0+3GBqSn70+R2HnUsQtFRzay5nvY2ZW9SVsU/XYO7E4JYhyYO4as3C xuHlAQ2XREhRUwTzHjxjOnNlWuoR+zlXoSmxa+EKjXDDHpFIJSGgiG94YXfjfsYidE86 ca82WUKCt9zpDVpz20ZaGNTzv8PPjs7l3Y0/E= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=from:content-type:content-transfer-encoding:subject:date:message-id :to:mime-version:x-mailer; b=ruzoXrtpQbFVYAtBMVtBXm6QeXPId4Ey2ZLuz3MG7F7iMdaYgRcZysP0qMLHXwcM9y szVQix27+I7ygJgPfncY7nga3aR6z9aRVgq8epih4RYwjgsNgJ/D6JAK7MnxF6Um3nmU IACj3OhSYPUvoofFPL7mb9TQgES+ceyZqJv04= Received: by 10.223.4.217 with SMTP id 25mr85457fas.82.1266565357910; Thu, 18 Feb 2010 23:42:37 -0800 (PST) Received: from mbp-gige.totalterror.net (93-152-151-19.ddns.onlinedirect.bg [93.152.151.19]) by mx.google.com with ESMTPS id p17sm2942670fka.5.2010.02.18.23.42.36 (version=TLSv1/SSLv3 cipher=RC4-MD5); Thu, 18 Feb 2010 23:42:36 -0800 (PST) From: Nikolay Denev Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Date: Fri, 19 Feb 2010 09:42:34 +0200 Message-Id: To: freebsd-fs@freebsd.org Mime-Version: 1.0 (Apple Message framework v1077) X-Mailer: Apple Mail (2.1077) Subject: ZFS write stalls (starving reads) and tuning zfs_write_limit_override X-BeenThere: freebsd-fs@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Filesystems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 19 Feb 2010 07:42:39 -0000 Hi, I'm experiencing a problem mentioned numerous times in the OpenSolaris = mailing lists, and that is IO stalls while ZFS commits the current TXG, which starves = all other IO. One of the solutions proposed there was to tune the = zfs_write_limit_override tunable, so the maximum TXG size could be smaller than the default (that I think = is auto-calculated from the available system memory) It seems that this is also available on FreeBSD but the tunable in = question was not declared az FreeBSD TUNABLE/SYSCTL, so I just went and added the following lines = : SYSCTL_DECL(_vfs_zfs); TUNABLE_ULONG("vfs.zfs.write_limit_override", = &zfs_write_limit_override); SYSCTL_ULONG(_vfs_zfs, OID_AUTO, zfs_write_limit_override, CTLFLAG_RW, = &zfs_write_limit_override, 0, "Override maximum TXG size"); to src/sys/cddl/contrib/opensolaris/uts/common/fs/zfs/dsl_pool.c at line = 50 With this tunable I'm now able to throttle/limit the write bursts and = this gives me a smoother iSCSI writes as opposed to the 5 sec periodic drops to zero IOPS/MBs = from before. -- Regards, Nikolay Denev From owner-freebsd-fs@FreeBSD.ORG Fri Feb 19 20:07:37 2010 Return-Path: Delivered-To: freebsd-fs@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 17C9110656F6; Fri, 19 Feb 2010 20:07:37 +0000 (UTC) (envelope-from pjd@garage.freebsd.pl) Received: from mail.garage.freebsd.pl (chello089077043238.chello.pl [89.77.43.238]) by mx1.freebsd.org (Postfix) with ESMTP id 2C4528FC17; Fri, 19 Feb 2010 20:07:35 +0000 (UTC) Received: by mail.garage.freebsd.pl (Postfix, from userid 65534) id 89D7A45E98; Fri, 19 Feb 2010 21:07:33 +0100 (CET) Received: from localhost (chello089077043238.chello.pl [89.77.43.238]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mail.garage.freebsd.pl (Postfix) with ESMTP id 1776945CD8; Fri, 19 Feb 2010 21:07:28 +0100 (CET) Date: Fri, 19 Feb 2010 21:07:25 +0100 From: Pawel Jakub Dawidek To: freebsd-fs@FreeBSD.org Message-ID: <20100219200725.GA1617@garage.freebsd.pl> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="T4sUOijqQbZv57TR" Content-Disposition: inline User-Agent: Mutt/1.4.2.3i X-PGP-Key-URL: http://people.freebsd.org/~pjd/pjd.asc X-OS: FreeBSD 9.0-CURRENT i386 X-Spam-Checker-Version: SpamAssassin 3.0.4 (2005-06-05) on mail.garage.freebsd.pl X-Spam-Level: X-Spam-Status: No, score=-0.6 required=4.5 tests=BAYES_00,RCVD_IN_SORBS_DUL autolearn=no version=3.0.4 Cc: freebsd-current@FreeBSD.org Subject: HAST (Highly Available Storage) now in HEAD. X-BeenThere: freebsd-fs@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Filesystems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 19 Feb 2010 20:07:37 -0000 --T4sUOijqQbZv57TR Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable Hi. Yesterday I committed HAST to the HEAD branch. HAST allows to transparently store data on two physically separated machines connected over the TCP/IP network. HAST works in Primary-Secondary (Master-Backup, Master-Slave) configuration, which means that only one of the cluster nodes can be active at any given time. Only Primary node is able to handle I/O requests to HAST-managed devices. Currently HAST is limited to two cluster nodes in total. HAST operates on block level - it provides disk-like devices in /dev/hast/ directory for use by file systems and/or applications. Working on block level makes it transparent for file systems and applications. There in no difference between using HAST-provided device and raw disk, partition, etc. All of them are just regular GEOM providers in FreeBSD. For more information please consult hastd(8), hastctl(8) and hast.conf(5) manual pages, as well as: http://wiki.FreeBSD.org/HAST On the wiki page above you should find instructions how to initialize hast and integrate it with ucarp. Let me know (using freebsd-fs@FreeBSD.org mailing list) if you have and questions or comments. And last, but not least, I'd like to thank sponsorswho made this projects possible: The FreeBSD Foundation, http://www.freebsdfoundation.org OMCnet Internet Service GmbH, http://www.omc.net TransIP BV, http://www.transip.nl --=20 Pawel Jakub Dawidek http://www.wheel.pl pjd@FreeBSD.org http://www.FreeBSD.org FreeBSD committer Am I Evil? Yes, I Am! --T4sUOijqQbZv57TR Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.14 (FreeBSD) iEYEARECAAYFAkt+73wACgkQForvXbEpPzQuTwCgnAXN3KLND3jHfHQeKZRTZq7P zXUAoNh46+aqQjk9prCIRtM0NzXj/Yzt =wjuQ -----END PGP SIGNATURE----- --T4sUOijqQbZv57TR-- From owner-freebsd-fs@FreeBSD.ORG Fri Feb 19 23:23:30 2010 Return-Path: Delivered-To: freebsd-fs@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id E74F0106568B; Fri, 19 Feb 2010 23:23:30 +0000 (UTC) (envelope-from alexz@visp.ru) Received: from mail.visp.ru (srv1.visp.ru [91.215.204.2]) by mx1.freebsd.org (Postfix) with ESMTP id 98F4C8FC13; Fri, 19 Feb 2010 23:23:29 +0000 (UTC) Received: from 91-215-205-255.static.visp.ru ([91.215.205.255] helo=zagrebin) by mail.visp.ru with esmtp (Exim 4.66 (FreeBSD)) (envelope-from ) id 1NicC0-000ND4-Kf; Sat, 20 Feb 2010 02:23:28 +0300 From: "Alexander Zagrebin" To: Date: Sat, 20 Feb 2010 02:23:28 +0300 Message-ID: <3A28259E0677447BBFDECFCCDBD97FD5@vosz.local> MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="----=_NextPart_000_0D69_01CAB1D3.B0549730" X-Mailer: Microsoft Office Outlook 11 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.5512 Thread-Index: AcqxuorLM1sfy3w2QYqffH6AzsTGsQ== Cc: freebsd-current@freebsd.org Subject: ZFS allows deletion of files in a sticky directory X-BeenThere: freebsd-fs@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Filesystems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 19 Feb 2010 23:23:31 -0000 This is a multi-part message in MIME format. ------=_NextPart_000_0D69_01CAB1D3.B0549730 Content-Type: text/plain; charset="koi8-r" Content-Transfer-Encoding: 7bit I have found that directory entry may be deleted from a ZFS directory with the sticky bit, if "the entry is a plain file and you have write access" (this is citation from a comments in zfs_dir.c) But this behavior isn't described in the sticky(8) and isn't allowed on a UFS. The attached patch provides the UFS-like behavior of a sticky directories on a ZFS. Is this bug or feature? -- Alexander Zagrebin ------=_NextPart_000_0D69_01CAB1D3.B0549730 Content-Type: application/octet-stream; name="patch-zfs_dir.c" Content-Transfer-Encoding: quoted-printable Content-Disposition: attachment; filename="patch-zfs_dir.c" --- = /usr/src/sys/cddl/contrib/opensolaris/uts/common/fs/zfs/zfs_dir.c.orig = 2009-07-20 23:16:42.000000000 +0400=0A= +++ /usr/src/sys/cddl/contrib/opensolaris/uts/common/fs/zfs/zfs_dir.c = 2010-02-20 01:23:45.112613715 +0300=0A= @@ -962,7 +962,6 @@=0A= *=0A= * you own the directory,=0A= * you own the entry,=0A= - * the entry is a plain file and you have write access,=0A= * or you are privileged (checked in secpolicy...).=0A= *=0A= * The function returns 0 if remove access is granted.=0A= @@ -984,9 +983,7 @@=0A= downer =3D zfs_fuid_map_id(zfsvfs, zdp->z_phys->zp_uid, cr, ZFS_OWNER);=0A= fowner =3D zfs_fuid_map_id(zfsvfs, zp->z_phys->zp_uid, cr, ZFS_OWNER);=0A= =0A= - if ((uid =3D crgetuid(cr)) =3D=3D downer || uid =3D=3D fowner ||=0A= - (ZTOV(zp)->v_type =3D=3D VREG &&=0A= - zfs_zaccess(zp, ACE_WRITE_DATA, 0, B_FALSE, cr) =3D=3D 0))=0A= + if ((uid =3D crgetuid(cr)) =3D=3D downer || uid =3D=3D fowner)=0A= return (0);=0A= else=0A= return (secpolicy_vnode_remove(ZTOV(zp), cr));=0A= ------=_NextPart_000_0D69_01CAB1D3.B0549730-- From owner-freebsd-fs@FreeBSD.ORG Fri Feb 19 23:37:56 2010 Return-Path: Delivered-To: freebsd-fs@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 67E491065676 for ; Fri, 19 Feb 2010 23:37:56 +0000 (UTC) (envelope-from pjd@garage.freebsd.pl) Received: from mail.garage.freebsd.pl (chello089077043238.chello.pl [89.77.43.238]) by mx1.freebsd.org (Postfix) with ESMTP id AAFF78FC17 for ; Fri, 19 Feb 2010 23:37:54 +0000 (UTC) Received: by mail.garage.freebsd.pl (Postfix, from userid 65534) id CF39045C89; Sat, 20 Feb 2010 00:37:52 +0100 (CET) Received: from localhost (chello089077043238.chello.pl [89.77.43.238]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mail.garage.freebsd.pl (Postfix) with ESMTP id C479845685; Sat, 20 Feb 2010 00:37:46 +0100 (CET) Date: Sat, 20 Feb 2010 00:37:44 +0100 From: Pawel Jakub Dawidek To: Garrett Cooper Message-ID: <20100219233744.GG1617@garage.freebsd.pl> References: <20100219200725.GA1617@garage.freebsd.pl> <7d6fde3d1002191511h4caac149tf39dcc37cf750afe@mail.gmail.com> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="VkqCAaSJIySsbD6j" Content-Disposition: inline In-Reply-To: <7d6fde3d1002191511h4caac149tf39dcc37cf750afe@mail.gmail.com> User-Agent: Mutt/1.4.2.3i X-PGP-Key-URL: http://people.freebsd.org/~pjd/pjd.asc X-OS: FreeBSD 9.0-CURRENT i386 X-Spam-Checker-Version: SpamAssassin 3.0.4 (2005-06-05) on mail.garage.freebsd.pl X-Spam-Level: X-Spam-Status: No, score=-0.6 required=4.5 tests=BAYES_00,RCVD_IN_SORBS_DUL autolearn=no version=3.0.4 Cc: freebsd-fs@freebsd.org Subject: Re: HAST (Highly Available Storage) now in HEAD. X-BeenThere: freebsd-fs@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Filesystems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 19 Feb 2010 23:37:56 -0000 --VkqCAaSJIySsbD6j Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Fri, Feb 19, 2010 at 03:11:44PM -0800, Garrett Cooper wrote: > Very cool stuff. How many nodes max are you targeting for this > service [...] Currently HAST is intended for use only with High Availability clusters, not for performance clusters and is limited to exactly two nodes - one primary node, which has access to shared storage and one secondary node, which just receives updates from primary. User's applications should only work on primary node. > [...] and what are some of the performance numbers for syncing > across the network (say with a 1GigE or 10GigE connection)? HAST should be able to saturate 1GigE link if you have fast enough storage. I've patches in the works to save data copying between userland and kernel. Currently, eg. write I/O request comes from the kernel, it is copied to hastd userland daemon, hastd copies it back to the kernel when writing to local component and then copies it again to the kernel when sending over network to secondary node. In other words a lot of copying. I prototyped a model where data is not copied at all between userland and kernel, but it needs a bit more work. --=20 Pawel Jakub Dawidek http://www.wheel.pl pjd@FreeBSD.org http://www.FreeBSD.org FreeBSD committer Am I Evil? Yes, I Am! --VkqCAaSJIySsbD6j Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.14 (FreeBSD) iEYEARECAAYFAkt/IMcACgkQForvXbEpPzTRagCdFSHqafi4fu9eBhaFrwXRcOmJ a38AoLdjFJ0iAs1IdobGLhJmsGFkvS+F =5QmY -----END PGP SIGNATURE----- --VkqCAaSJIySsbD6j-- From owner-freebsd-fs@FreeBSD.ORG Fri Feb 19 23:41:37 2010 Return-Path: Delivered-To: freebsd-fs@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 150B4106566C for ; Fri, 19 Feb 2010 23:41:37 +0000 (UTC) (envelope-from yanefbsd@gmail.com) Received: from mail-pw0-f54.google.com (mail-pw0-f54.google.com [209.85.160.54]) by mx1.freebsd.org (Postfix) with ESMTP id D61908FC0A for ; Fri, 19 Feb 2010 23:41:36 +0000 (UTC) Received: by pwj7 with SMTP id 7so736034pwj.13 for ; Fri, 19 Feb 2010 15:41:36 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:in-reply-to:references :date:message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=hD/3bUOmzoRmvTaQgnqVU08/6391gk/6Tl9KkRPtrC0=; b=opmyGhL3rY0OFWhCcNG0hl61hR9HAPtPSnT0/kjGLWwbU4UuyUG8P+G9Xe0Dh2OMgx q5thn+RnggCLCCpcxryREVIH7zb+UB/MehJ6nl01tcoZsbumK9LEpBPiGJL+XcMmgAmu v1nkZ8ol1hhEw2+QhHNbkGbJ1FZzo06H4Prk8= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; b=wV6p2dSbuDmQ697tXcz5YCGEh3rb64LKUWFu3zlZ91O01hN9fJLDZxdgfv0lyWBD/Z 4qQuE3b28816/eB5/BbXetll7DXG+vmwFMzRYituNf1zI4yTD2FaM7v4LyDJD3uzEW2b yp9ZB798YHqysU3HUsGXSIEcJW+puFmpP96Es= MIME-Version: 1.0 Received: by 10.142.59.4 with SMTP id h4mr7800047wfa.187.1266621104375; Fri, 19 Feb 2010 15:11:44 -0800 (PST) In-Reply-To: <20100219200725.GA1617@garage.freebsd.pl> References: <20100219200725.GA1617@garage.freebsd.pl> Date: Fri, 19 Feb 2010 15:11:44 -0800 Message-ID: <7d6fde3d1002191511h4caac149tf39dcc37cf750afe@mail.gmail.com> From: Garrett Cooper To: Pawel Jakub Dawidek Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: freebsd-fs@freebsd.org Subject: Re: HAST (Highly Available Storage) now in HEAD. X-BeenThere: freebsd-fs@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Filesystems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 19 Feb 2010 23:41:37 -0000 On Fri, Feb 19, 2010 at 12:07 PM, Pawel Jakub Dawidek wro= te: > Hi. > > Yesterday I committed HAST to the HEAD branch. > > HAST allows to transparently store data on two physically separated > machines connected over the TCP/IP network. HAST works in > Primary-Secondary (Master-Backup, Master-Slave) configuration, which > means that only one of the cluster nodes can be active at any given > time. Only Primary node is able to handle I/O requests to HAST-managed > devices. Currently HAST is limited to two cluster nodes in total. > > HAST operates on block level - it provides disk-like devices in > /dev/hast/ directory for use by file systems and/or applications. > Working on block level makes it transparent for file systems and > applications. There in no difference between using HAST-provided device > and raw disk, partition, etc. All of them are just regular GEOM > providers in FreeBSD. > > For more information please consult hastd(8), hastctl(8) and > hast.conf(5) manual pages, as well as: > > =A0 =A0 =A0 =A0http://wiki.FreeBSD.org/HAST > > On the wiki page above you should find instructions how to initialize > hast and integrate it with ucarp. Very cool stuff. How many nodes max are you targeting for this service and what are some of the performance numbers for syncing across the network (say with a 1GigE or 10GigE connection)? Cheers, -Garrett From owner-freebsd-fs@FreeBSD.ORG Fri Feb 19 23:41:42 2010 Return-Path: Delivered-To: freebsd-fs@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 8A30D106568D; Fri, 19 Feb 2010 23:41:42 +0000 (UTC) (envelope-from yanefbsd@gmail.com) Received: from mail-px0-f180.google.com (mail-px0-f180.google.com [209.85.216.180]) by mx1.freebsd.org (Postfix) with ESMTP id 5ABCA8FC14; Fri, 19 Feb 2010 23:41:42 +0000 (UTC) Received: by pxi10 with SMTP id 10so401208pxi.13 for ; Fri, 19 Feb 2010 15:41:42 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:in-reply-to:references :date:message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=9XTAyw02DJicC3DXxRSMjkkuMMFqhla6sPbwi4OYaKg=; b=ZoAUz8QkxpaqFps+z33KNCKMtez2s6sROz1lYZ9V1YQcoiV41PhOxecgwKlCcviW4d XFq5WyUFvVari+0FeoJ19IscaGSUPvJ6q3GMnvwBAiayKjjZkGHmQXTdnqcSc621iJ0z CjbgWP88CRyoduM3NMUnMowN0O/srTiY+I624= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; b=MMNIioJFm+TAAfOg7bG3sl3qkiFNiX7iFSoMp38TlUnHWHoedkJnvrYSp38w18xYb2 HgNsyR2kaTWEnACVbP2fknkDfliJTWqsvt1tIep0Uy+iKlakiv3JxBNnXaiD/0MTbhcJ Nsrs3Z5F7xIf+NCchrWCsUaE1ge+tP9KrBrRU= MIME-Version: 1.0 Received: by 10.142.249.16 with SMTP id w16mr3142851wfh.346.1266622901949; Fri, 19 Feb 2010 15:41:41 -0800 (PST) In-Reply-To: <20100219233744.GG1617@garage.freebsd.pl> References: <20100219200725.GA1617@garage.freebsd.pl> <7d6fde3d1002191511h4caac149tf39dcc37cf750afe@mail.gmail.com> <20100219233744.GG1617@garage.freebsd.pl> Date: Fri, 19 Feb 2010 15:41:41 -0800 Message-ID: <7d6fde3d1002191541k51ab8526ub18a7c05484112f5@mail.gmail.com> From: Garrett Cooper To: Pawel Jakub Dawidek Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: freebsd-fs@freebsd.org Subject: Re: HAST (Highly Available Storage) now in HEAD. X-BeenThere: freebsd-fs@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Filesystems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 19 Feb 2010 23:41:42 -0000 On Fri, Feb 19, 2010 at 3:37 PM, Pawel Jakub Dawidek wrot= e: > On Fri, Feb 19, 2010 at 03:11:44PM -0800, Garrett Cooper wrote: >> =A0 =A0 Very cool stuff. How many nodes max are you targeting for this >> service [...] > > Currently HAST is intended for use only with High Availability clusters, > not for performance clusters and is limited to exactly two nodes - one > primary node, which has access to shared storage and one secondary node, > which just receives updates from primary. User's applications should > only work on primary node. I was looking forward a bit more than what's setup today TBH, but that's ok= ... >> [...] and what are some of the performance numbers for syncing >> across the network (say with a 1GigE or 10GigE connection)? > > HAST should be able to saturate 1GigE link if you have fast enough > storage. I've patches in the works to save data copying between userland > and kernel. Currently, eg. write I/O request comes from the kernel, it > is copied to hastd userland daemon, hastd copies it back to the kernel > when writing to local component and then copies it again to the kernel > when sending over network to secondary node. In other words a lot of > copying. I prototyped a model where data is not copied at all between > userland and kernel, but it needs a bit more work. Ouch. Lots of CoW / copyout...? Is the data being checksummed / verified somewhere to ensure integrity at all (I would think so / hope so...)? Cheers! -Garrett From owner-freebsd-fs@FreeBSD.ORG Fri Feb 19 23:42:28 2010 Return-Path: Delivered-To: freebsd-fs@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 55D1B106566B for ; Fri, 19 Feb 2010 23:42:28 +0000 (UTC) (envelope-from fjwcash@gmail.com) Received: from mail-yx0-f172.google.com (mail-yx0-f172.google.com [209.85.210.172]) by mx1.freebsd.org (Postfix) with ESMTP id 1342F8FC0C for ; Fri, 19 Feb 2010 23:42:27 +0000 (UTC) Received: by yxe2 with SMTP id 2so593313yxe.7 for ; Fri, 19 Feb 2010 15:42:27 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:in-reply-to:references :date:message-id:subject:from:to:content-type; bh=MYISlmZy8gKVywGeRO8qYRgj9wAJntXBYsstr11rMaU=; b=HC0Q4toDQXDN8XO96H7USvbMK/K6hcJpxrirtRVw3IHNUUPngq7ItkUMBOX63MRgJW R1JrHT8vp0A8BTWqhwW9VD9yDIscuFfjQOtdf1EP9KsHEDXIgOTtMrdlXpia9KA1dfjC Rte4uuf1ZiwW6IqzfDvutZVaseWNkltD+gM3I= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :content-type; b=Ln091oQCxBBn7g5fyEMo4lAX79UOEzGqJE/cnJ5kiztZgScqz2AnV+8mes0J2Kd/wb E8x1p0BCZt6IsIpObocsx2xJI8R5jeORlM8hdjwyiq715EKXGjx7U9I0L/rXvphwcEhn c4bMLs7179T31pGz3Ys2NR3hwYBu16OURMcEM= MIME-Version: 1.0 Received: by 10.231.172.129 with SMTP id l1mr285160ibz.7.1266622945605; Fri, 19 Feb 2010 15:42:25 -0800 (PST) In-Reply-To: <20100219200725.GA1617@garage.freebsd.pl> References: <20100219200725.GA1617@garage.freebsd.pl> Date: Fri, 19 Feb 2010 15:42:25 -0800 Message-ID: From: Freddie Cash To: freebsd-fs@freebsd.org Content-Type: text/plain; charset=UTF-8 X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Subject: Re: HAST (Highly Available Storage) now in HEAD. X-BeenThere: freebsd-fs@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Filesystems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 19 Feb 2010 23:42:28 -0000 On Fri, Feb 19, 2010 at 12:07 PM, Pawel Jakub Dawidek wrote: > Yesterday I committed HAST to the HEAD branch. > > NICE!!! Excellent work! Can't wait to test it, although I'm a little leery about running -CURRENT. I'll have to fire up some VMs over the weekend. :) Two quick questions 1. Are there any plans to MFC this to stable/8? 2. Is this usable for a boot device? I'm thinking no (or not yet), but want to double-check. -- Freddie Cash fjwcash@gmail.com From owner-freebsd-fs@FreeBSD.ORG Fri Feb 19 23:57:34 2010 Return-Path: Delivered-To: freebsd-fs@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 70424106566B for ; Fri, 19 Feb 2010 23:57:34 +0000 (UTC) (envelope-from mj@feral.com) Received: from ns1.feral.com (ns1.feral.com [192.67.166.1]) by mx1.freebsd.org (Postfix) with ESMTP id 3846E8FC15 for ; Fri, 19 Feb 2010 23:57:33 +0000 (UTC) Received: from [192.168.0.101] (m206-63.dsl.tsoft.com [198.144.206.63]) by ns1.feral.com (8.14.3/8.14.3) with ESMTP id o1JNvXEP042234 for ; Fri, 19 Feb 2010 15:57:33 -0800 (PST) (envelope-from mj@feral.com) Message-ID: <4B7F2576.4060105@feral.com> Date: Fri, 19 Feb 2010 15:57:42 -0800 From: Matthew Jacob User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.1.7) Gecko/20100111 Thunderbird/3.0.1 MIME-Version: 1.0 To: freebsd-fs@freebsd.org References: <20100219200725.GA1617@garage.freebsd.pl> In-Reply-To: <20100219200725.GA1617@garage.freebsd.pl> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Greylist: Sender DNS name whitelisted, not delayed by milter-greylist-4.2.3 (ns1.feral.com [192.67.166.1]); Fri, 19 Feb 2010 15:57:33 -0800 (PST) Subject: Re: HAST (Highly Available Storage) now in HEAD. X-BeenThere: freebsd-fs@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Filesystems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 19 Feb 2010 23:57:34 -0000 Very nice indeed. This hopefully can also be the platform to add to for other features too, I hope (e.g., CDP). From owner-freebsd-fs@FreeBSD.ORG Sat Feb 20 00:08:08 2010 Return-Path: Delivered-To: freebsd-fs@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 2B26A106566C for ; Sat, 20 Feb 2010 00:08:08 +0000 (UTC) (envelope-from pjd@garage.freebsd.pl) Received: from mail.garage.freebsd.pl (chello089077043238.chello.pl [89.77.43.238]) by mx1.freebsd.org (Postfix) with ESMTP id 69B188FC08 for ; Sat, 20 Feb 2010 00:08:07 +0000 (UTC) Received: by mail.garage.freebsd.pl (Postfix, from userid 65534) id 221FC45CDC; Sat, 20 Feb 2010 01:08:06 +0100 (CET) Received: from localhost (chello089077043238.chello.pl [89.77.43.238]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mail.garage.freebsd.pl (Postfix) with ESMTP id 0E10045CA6; Sat, 20 Feb 2010 01:08:00 +0100 (CET) Date: Sat, 20 Feb 2010 01:07:58 +0100 From: Pawel Jakub Dawidek To: Garrett Cooper Message-ID: <20100220000758.GI1617@garage.freebsd.pl> References: <20100219200725.GA1617@garage.freebsd.pl> <7d6fde3d1002191511h4caac149tf39dcc37cf750afe@mail.gmail.com> <20100219233744.GG1617@garage.freebsd.pl> <7d6fde3d1002191541k51ab8526ub18a7c05484112f5@mail.gmail.com> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="aznLbwQ42o7LEaqN" Content-Disposition: inline In-Reply-To: <7d6fde3d1002191541k51ab8526ub18a7c05484112f5@mail.gmail.com> User-Agent: Mutt/1.4.2.3i X-PGP-Key-URL: http://people.freebsd.org/~pjd/pjd.asc X-OS: FreeBSD 9.0-CURRENT i386 X-Spam-Checker-Version: SpamAssassin 3.0.4 (2005-06-05) on mail.garage.freebsd.pl X-Spam-Level: X-Spam-Status: No, score=-0.6 required=4.5 tests=BAYES_00,RCVD_IN_SORBS_DUL autolearn=no version=3.0.4 Cc: freebsd-fs@freebsd.org Subject: Re: HAST (Highly Available Storage) now in HEAD. X-BeenThere: freebsd-fs@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Filesystems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 20 Feb 2010 00:08:08 -0000 --aznLbwQ42o7LEaqN Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Fri, Feb 19, 2010 at 03:41:41PM -0800, Garrett Cooper wrote: > On Fri, Feb 19, 2010 at 3:37 PM, Pawel Jakub Dawidek wr= ote: > > On Fri, Feb 19, 2010 at 03:11:44PM -0800, Garrett Cooper wrote: > >> =A0 =A0 Very cool stuff. How many nodes max are you targeting for this > >> service [...] > > > > Currently HAST is intended for use only with High Availability clusters, > > not for performance clusters and is limited to exactly two nodes - one > > primary node, which has access to shared storage and one secondary node, > > which just receives updates from primary. User's applications should > > only work on primary node. >=20 > I was looking forward a bit more than what's setup today TBH, but that's = ok... What exactly were you expecting? Even if HAST would be able to operate in multi-master mode, I don't think we have any file system that can take advantage of such configuration. Also note that DRBD, which is on the market for a long time already can operate also only in primary-secondary configuration for production uses. Eventhough it supports primary-primary configuration, it is not recommended for production use AFAIK. If you describe your needs, we might be able to figure something out. > [...] Is the data being checksummed / > verified somewhere to ensure integrity at all (I would think so / hope > so...)? You mean on-disk on on-wire? There is initial code in HAST to checksum data on-wire, but not yet finished. Checksumming data on-disk is not planed for HAST, it can be done using different GEOM classes, like geli. The most sense currently makes putting ZFS on HAST, because with UFS switching between the nodes will take a long time thanks to fsck. And once you are using ZFS you get checksumming for free (on both disk and wire). --=20 Pawel Jakub Dawidek http://www.wheel.pl pjd@FreeBSD.org http://www.FreeBSD.org FreeBSD committer Am I Evil? Yes, I Am! --aznLbwQ42o7LEaqN Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.14 (FreeBSD) iEYEARECAAYFAkt/J94ACgkQForvXbEpPzT6GwCg1Gh616DCpk6pO57WxivB18My MdkAoJ2YeStG/1ueLYCaQaVwY2OkEm3t =MeYL -----END PGP SIGNATURE----- --aznLbwQ42o7LEaqN-- From owner-freebsd-fs@FreeBSD.ORG Sat Feb 20 10:05:25 2010 Return-Path: Delivered-To: freebsd-fs@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 460DA106566C for ; Sat, 20 Feb 2010 10:05:25 +0000 (UTC) (envelope-from mailinglists@debank.tv) Received: from smtpout01.onlinespamfilter.nl (smtpout01.onlinespamfilter.nl [217.21.240.161]) by mx1.freebsd.org (Postfix) with ESMTP id F294F8FC17 for ; Sat, 20 Feb 2010 10:05:24 +0000 (UTC) Received: from smtp.onlinespamfilter.nl (localhost [127.0.0.1]) by smtp.onlinespamfilter.nl (Postfix) with ESMTP id 7427425079 for ; Sat, 20 Feb 2010 10:47:04 +0100 (CET) Received: from smtp.debank.tv (59-80-ftth.onsneteindhoven.nl [88.159.80.59]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by smtp.onlinespamfilter.nl (Postfix) with ESMTP for ; Sat, 20 Feb 2010 10:47:04 +0100 (CET) Received: from smtp.debank.tv (smtp.debank.tv [172.16.143.25]) by smtp.debank.tv (Postfix) with ESMTP id 2B3371DB2161 for ; Sat, 20 Feb 2010 10:47:04 +0100 (CET) Received: from Rob-Everss-Mac-Pro.local (121-73-247-214.broadband.telstraclear.net [121.73.247.214]) (using SSLv3 with cipher DHE-RSA-CAMELLIA256-SHA (256/256 bits)) (No client certificate requested) (Authenticated sender: rob) by smtp.debank.tv (Postfix) with ESMTPSA id 659F11DB1FDA for ; Sat, 20 Feb 2010 10:47:03 +0100 (CET) Message-ID: Date: Sat, 20 Feb 2010 22:47:05 +1300 From: mailinglists User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.6; en-US; rv:1.9.1.7) Gecko/20100111 Thunderbird/3.0.1 MIME-Version: 1.0 To: freebsd-fs@freebsd.org Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Virus-Scanned: ClamAV using ClamSMTP @ debank.tv X-OSF-Virus: CLEAN X-OSF-Outgoing: Innocent X-OSF-SUM: e7531071831ef4c088902a8b5fe94dab X-OSF-Info: Checked for spam and viruses Subject: zfs on 4k sector disks X-BeenThere: freebsd-fs@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Filesystems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 20 Feb 2010 10:05:25 -0000 Hello, I've got 3 1.5TB drives that are using the "Advanced Format" from Western Digital, see the link for details: http://www.wdc.com/wdproducts/library/WhitePapers/ENG/2579-771430.pdf This "Advanced Format" basically means the sectors size on disk is changed to 4k in stead of 512k. I'm wondering if freeBSD 8.0 using ZFS raidz and drives like these will work properly, I've seen a lot of articles and postings about partitions not being properly aligned with the physical disk layout and suffering big performance hits. My question is; should I worry about these issues or does ZFS already align the data on a 4k border? My setup would be 3 * 1.5TB WD drives (WD15EARS) using the whole drive for a raidz pool. Thanks, Rob Evers ***deze e-mail is gescand door Onlinespamfilter.nl*** From owner-freebsd-fs@FreeBSD.ORG Sat Feb 20 12:25:55 2010 Return-Path: Delivered-To: freebsd-fs@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id CCF29106566C for ; Sat, 20 Feb 2010 12:25:55 +0000 (UTC) (envelope-from dimitry@andric.com) Received: from tensor.andric.com (cl-327.ede-01.nl.sixxs.net [IPv6:2001:7b8:2ff:146::2]) by mx1.freebsd.org (Postfix) with ESMTP id 959EC8FC0C for ; Sat, 20 Feb 2010 12:25:55 +0000 (UTC) Received: from [IPv6:2001:7b8:3a7:0:705d:318e:2cb0:5f81] (unknown [IPv6:2001:7b8:3a7:0:705d:318e:2cb0:5f81]) (using TLSv1 with cipher DHE-RSA-CAMELLIA256-SHA (256/256 bits)) (No client certificate requested) by tensor.andric.com (Postfix) with ESMTPSA id D9DD25C59; Sat, 20 Feb 2010 13:25:52 +0100 (CET) Message-ID: <4B7FD4D2.7040802@andric.com> Date: Sat, 20 Feb 2010 13:25:54 +0100 From: Dimitry Andric User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.2; en-US; rv:1.9.2.2pre) Gecko/20100218 Lanikai/3.1b1pre MIME-Version: 1.0 To: mailinglists References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: freebsd-fs@freebsd.org Subject: Re: zfs on 4k sector disks X-BeenThere: freebsd-fs@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Filesystems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 20 Feb 2010 12:25:55 -0000 On 2010-02-20 10:47, mailinglists wrote: > This "Advanced Format" basically means the sectors size on disk is > changed to 4k in stead of 512k. Please note those disks still seem to expose 512B sectors to any OS; the 4kiB sectors are only used internally. And there seems to be no jumper to "fix" this behaviour... Unaligned writes can cause multiple read-write-modify operations, which are most likely bad for performance. > I'm wondering if freeBSD 8.0 using ZFS raidz and drives like these will > work properly, I've seen a lot of articles and postings about partitions > not being properly aligned with the physical disk layout and suffering > big performance hits. My question is; should I worry about these issues > or does ZFS already align the data on a 4k border? You can at least try to make sure your partitions are aligned to 4kiB. This should be easy enough to do with e.g. gpart(8). I see no specific alignment options in the zpool(1M) or zfs(1M) manpages, but there may be some trick that I am not aware of. :) With UFS, you might want to experiment with block and fragment sizes, to see what is most optimal. For example, a block size of 32kiB and fragment size of 4kiB, on a partition aligned to 4kiB. From owner-freebsd-fs@FreeBSD.ORG Sat Feb 20 21:34:18 2010 Return-Path: Delivered-To: freebsd-fs@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 3CB24106566C for ; Sat, 20 Feb 2010 21:34:18 +0000 (UTC) (envelope-from rbgarga@gmail.com) Received: from mail-ew0-f214.google.com (mail-ew0-f214.google.com [209.85.219.214]) by mx1.freebsd.org (Postfix) with ESMTP id C74518FC0C for ; Sat, 20 Feb 2010 21:34:17 +0000 (UTC) Received: by ewy6 with SMTP id 6so1459220ewy.34 for ; Sat, 20 Feb 2010 13:34:16 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:in-reply-to:references :from:date:message-id:subject:to:cc:content-type :content-transfer-encoding; bh=oRUUeZWIyVmSgEJCDHincRKPLSVvQZojhI2DhSJtNZI=; b=l62Qz7UE/7u+LVcWfyqt6PD9aoDNqNcAG3+iZSAy448mZe/aPkwRIlVUJvRNSWQ/ZE JB5tS+FjxOMa/Y2HPDY4YH6q7qQC+MEMfxxYD1MOLES7KznymnPxxmmfvVwrfVl1z012 OKDBovtAugM0Vbpy0oZXQag8Y/CYkuccUt9Hs= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type:content-transfer-encoding; b=TdIVMMOYuv8pw8G0REKVyfccrNX6TZv39thMtWzL6ZiSyNDHjeg9MYTVQWJaDdbTrA Zg1EehpM0fFsFxHkTmUpS7VBs4z2LBWcgTzu6Rrk9RCMmBqo/EExgaWeMFW45OyGQqIs +qjsJAUN2B4HTCqjmhuePiEfnsCLsOdLeOK4k= MIME-Version: 1.0 Received: by 10.216.85.143 with SMTP id u15mr2002490wee.205.1266700318155; Sat, 20 Feb 2010 13:11:58 -0800 (PST) In-Reply-To: <20100219200725.GA1617@garage.freebsd.pl> References: <20100219200725.GA1617@garage.freebsd.pl> From: Renato Botelho Date: Sat, 20 Feb 2010 18:11:38 -0300 Message-ID: <747dc8f31002201311k2131a74ake3de75ab1aec9e43@mail.gmail.com> To: Pawel Jakub Dawidek Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: freebsd-fs@freebsd.org, freebsd-current@freebsd.org Subject: Re: HAST (Highly Available Storage) now in HEAD. X-BeenThere: freebsd-fs@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Filesystems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 20 Feb 2010 21:34:18 -0000 On Fri, Feb 19, 2010 at 5:07 PM, Pawel Jakub Dawidek wrot= e: > Hi. > > Yesterday I committed HAST to the HEAD branch. > > HAST allows to transparently store data on two physically separated > machines connected over the TCP/IP network. HAST works in > Primary-Secondary (Master-Backup, Master-Slave) configuration, which > means that only one of the cluster nodes can be active at any given > time. Only Primary node is able to handle I/O requests to HAST-managed > devices. Currently HAST is limited to two cluster nodes in total. > > HAST operates on block level - it provides disk-like devices in > /dev/hast/ directory for use by file systems and/or applications. > Working on block level makes it transparent for file systems and > applications. There in no difference between using HAST-provided device > and raw disk, partition, etc. All of them are just regular GEOM > providers in FreeBSD. > > For more information please consult hastd(8), hastctl(8) and > hast.conf(5) manual pages, as well as: > > =A0 =A0 =A0 =A0http://wiki.FreeBSD.org/HAST > > On the wiki page above you should find instructions how to initialize > hast and integrate it with ucarp. > > Let me know (using freebsd-fs@FreeBSD.org mailing list) if you have and > questions or comments. > > And last, but not least, I'd like to thank sponsorswho made this > projects possible: > > =A0 =A0 =A0 =A0The FreeBSD Foundation, http://www.freebsdfoundation.org > =A0 =A0 =A0 =A0OMCnet Internet Service GmbH, http://www.omc.net > =A0 =A0 =A0 =A0TransIP BV, http://www.transip.nl It's great news, thank you for your hard work!!! --=20 Renato Botelho From owner-freebsd-fs@FreeBSD.ORG Sat Feb 20 22:19:40 2010 Return-Path: Delivered-To: freebsd-fs@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 86EB0106566C; Sat, 20 Feb 2010 22:19:40 +0000 (UTC) (envelope-from asmrookie@gmail.com) Received: from mail-iw0-f185.google.com (mail-iw0-f185.google.com [209.85.223.185]) by mx1.freebsd.org (Postfix) with ESMTP id 1EFE58FC08; Sat, 20 Feb 2010 22:19:39 +0000 (UTC) Received: by iwn15 with SMTP id 15so1350858iwn.7 for ; Sat, 20 Feb 2010 14:19:39 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:sender:received:in-reply-to :references:date:x-google-sender-auth:message-id:subject:from:to:cc :content-type:content-transfer-encoding; bh=n+90xLH9qr8zVsECyDAh5icnNh6C+ve2ovdINOaP7Lg=; b=QhAEuGgmoT9D40iq/ooqVidTfw3sauC7L6hX5+ZQ313a7usG0bS448tmSoktds5W+J f0N6DctkkVvXRr/UpiCqc8hk+nMmaR/MsA1P1gYnB8fcbLOCYsSYgw+QCwLL6vojcc2N UNFAAXVH5EQpWgu5iAX0BpCrClh6TKDLomYeQ= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type :content-transfer-encoding; b=kSBqHTntFome8WJfSpA9RQNB/iTV0ysfzhwymF4S/oXtb3cYCHVkGskso+sv/ZV0iO nkrPTmz5twA/h2HPr1yh4PJoDcWoMmLTbDGUGt1zQi/hYPA8jyvodKswNyp+kVEHXj+E 4wtuVw/cVVSBUBbG9rb1nWFReEGz14mY/kcTg= MIME-Version: 1.0 Sender: asmrookie@gmail.com Received: by 10.231.144.201 with SMTP id a9mr2641556ibv.69.1266704379191; Sat, 20 Feb 2010 14:19:39 -0800 (PST) In-Reply-To: <179b97fb1001270941m2d8e9c8au20abc798c16b9c11@mail.gmail.com> References: <179b97fb1001270941m2d8e9c8au20abc798c16b9c11@mail.gmail.com> Date: Sat, 20 Feb 2010 23:19:39 +0100 X-Google-Sender-Auth: 5d13842cfb9ed9df Message-ID: <3bbf2fe11002201419v52b249ccg8d82c8ae747cf318@mail.gmail.com> From: Attilio Rao To: Brandon Gooch Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Cc: freebsd-fs@freebsd.org, freebsd-emulation@freebsd.org, stable-list freebsd Subject: Re: ZFS and sh(1) panic: spin lock [lock addr] (smp rendezvous) held by [sh(1) proc tid] too long X-BeenThere: freebsd-fs@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Filesystems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 20 Feb 2010 22:19:40 -0000 2010/1/27 Brandon Gooch : > The machine, a Dell Optiplex 755, has been locking up recently. The > situation usually occurs while using VirtualBox (running a 64-bit > Windows 7 instance) and doing anything else in another xterm (such as > rebuilding a port). =C2=A0I've been unable to reliably reproduce it (I'm = in > an X session and the machine will not panic "properly"). > > However, while rebuilding Xorg today at ttyv0 and runnning > VBoxHeadless on ttyv1, I managed to trigger what I believe is the > lockup. > > I've attached a textdump in hopes that someone may be able to take a > look and provide clues or instruction on debugging this. I think that jhb@ saw a similar problem while working on nVidia driver or the like. Not sure if he made any progress to debug this. Attilio --=20 Peace can only be achieved by understanding - A. Einstein