From owner-freebsd-fs@FreeBSD.ORG Sun May 22 09:30:10 2005 Return-Path: X-Original-To: freebsd-fs@freebsd.org Delivered-To: freebsd-fs@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 155E616A41C for ; Sun, 22 May 2005 09:30:10 +0000 (GMT) (envelope-from clive@tongi.org) Received: from drop.bsdchat.com (drop.bsdchat.com [209.237.225.38]) by mx1.FreeBSD.org (Postfix) with ESMTP id D821C43D49 for ; Sun, 22 May 2005 09:30:09 +0000 (GMT) (envelope-from clive@tongi.org) Received: from CARTIER (drag.bsdchat.com [209.237.225.37]) by drop.bsdchat.com (8.13.3/8.13.3) with SMTP id j4M9Trbf046788; Sun, 22 May 2005 09:29:55 GMT (envelope-from clive@tongi.org) Received: (nullmailer pid 1282 invoked by uid 1000); Sun, 22 May 2005 09:29:27 -0000 Date: Sun, 22 May 2005 17:29:27 +0800 From: Clive Lin To: =?iso-8859-1?Q?Herv=E9?= Kergourlay Message-ID: <20050522092926.GA1042@tongi.org> References: <427F491C.4090501@club-internet.fr> <427F9404.8060509@samsco.org> <42834982.40302@club-internet.fr> <42834CF9.6060301@atempo.com> Mime-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: quoted-printable In-Reply-To: <42834CF9.6060301@atempo.com> X-PGP-key: http://pgp.mit.edu:11371/pks/lookup?op=get&search=0xA008C03E User-Agent: Mutt/1.5.9i X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-1.6 (drop.bsdchat.com [209.237.225.38]); Sun, 22 May 2005 09:29:56 +0000 (UTC) Cc: freebsd-fs@freebsd.org Subject: Re: setfacl -d 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, 22 May 2005 09:30:10 -0000 On Thu, May 12, 2005 at 02:32:57PM +0200, Herv=E9 Kergourlay wrote: > how to set a default ACl on directory on FreeBSD 5.3 >=20 > the setfacl -d failed with the following message >=20 > fiobsd.hky(290) [dev->acl] setfacl -d -m u::rw- dir1 > setfacl: acl_calc_mask() failed: Invalid argument > setfacl: failed to set ACL mask on dir1 Hi, For freshly created directory, you have to do 'setfacl -m ...' first. $ mkdir aclTest $ setfacl -d -m u:clive:rwx aclTest setfacl: acl_calc_mask() failed: Invalid argument setfacl: failed to set ACL mask on aclTest $ setfacl -m u:clive:rwx aclTest $ getfacl aclTest | setfacl -d -b -n -M - aclTest $ getfacl -d aclTest|grep clive user:clive:rwx --=20 Clive Tong-I Lin | http://tongi.org | PGP KeyID: A008C03E From owner-freebsd-fs@FreeBSD.ORG Mon May 23 11:57:05 2005 Return-Path: X-Original-To: freebsd-fs@freebsd.org Delivered-To: freebsd-fs@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id B359316A41C for ; Mon, 23 May 2005 11:57:05 +0000 (GMT) (envelope-from herve.kergourlay@atempo.com) Received: from ds9.atempo.com (ds9.atempo.com [212.157.146.98]) by mx1.FreeBSD.org (Postfix) with ESMTP id EA94643D49 for ; Mon, 23 May 2005 11:57:04 +0000 (GMT) (envelope-from herve.kergourlay@atempo.com) Received: from ds9.atempo.com (localhost.localdomain [127.0.0.1]) by localhost.atempo.com (Postfix) with ESMTP id C52A72FD47; Mon, 23 May 2005 13:57:00 +0200 (CEST) Received: from atempo.com (unknown [172.16.15.140])by ds9.atempo.com (Postfix) with ESMTP id B47702FD45; Mon, 23 May 2005 13:57:00 +0200 (CEST) Received: from [192.168.2.108] (aragorn.vannes.quadratec.fr [192.168.2.108])by atempo.com (Postfix) with ESMTP id 3BE5A1E3257; Mon, 23 May 2005 13:57:00 +0200 (CEST) Message-ID: <4291C50B.1090505@atempo.com> Date: Mon, 23 May 2005 13:56:59 +0200 From: =?ISO-8859-1?Q?Herv=E9_Kergourlay?= User-Agent: Mozilla Thunderbird 1.0 (Windows/20041206) X-Accept-Language: fr, en MIME-Version: 1.0 To: Clive Lin References: <427F491C.4090501@club-internet.fr> <427F9404.8060509@samsco.org> <42834982.40302@club-internet.fr> <42834CF9.6060301@atempo.com> <20050522092926.GA1042@tongi.org> In-Reply-To: <20050522092926.GA1042@tongi.org> X-Enigmail-Version: 0.90.0.0 X-Enigmail-Supports: pgp-inline, pgp-mime Content-Type: multipart/mixed; boundary=------------070004090505050904090703 X-imss-version: 2.025 X-imss-result: Passed X-imss-approveListMatch: *@atempo.com X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Cc: freebsd-fs@freebsd.org Subject: Re: setfacl -d 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, 23 May 2005 11:57:05 -0000 This is a multi-part message in MIME format. --------------070004090505050904090703 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit Clive Lin a écrit : >On Thu, May 12, 2005 at 02:32:57PM +0200, Hervé Kergourlay wrote: > > >>how to set a default ACl on directory on FreeBSD 5.3 >> >>the setfacl -d failed with the following message >> >>fiobsd.hky(290) [dev->acl] setfacl -d -m u::rw- dir1 >>setfacl: acl_calc_mask() failed: Invalid argument >>setfacl: failed to set ACL mask on dir1 >> >> > >Hi, > > For freshly created directory, you have to do 'setfacl -m ...' first. > >$ mkdir aclTest >$ setfacl -d -m u:clive:rwx aclTest >setfacl: acl_calc_mask() failed: Invalid argument >setfacl: failed to set ACL mask on aclTest >$ setfacl -m u:clive:rwx aclTest >$ getfacl aclTest | setfacl -d -b -n -M - aclTest >$ getfacl -d aclTest|grep clive >user:clive:rwx > > thanks it's effectively working but it's a very complex method, how can the standard user knows that ? now I've discovered another problem with the API acl_ser_file with a valid path, a valid acl parameter and a 0 type (ACCESS), I've the error code 22 (EINVAL) when setting tha following acls on a file "user::rw-\nuser:froupie:r-x # effective: r--\ngroup::r-x # effective: r--\nmask::r--\nother::r--\n" is it normal ? hervé --------------070004090505050904090703-- From owner-freebsd-fs@FreeBSD.ORG Mon May 23 16:44:21 2005 Return-Path: X-Original-To: freebsd-fs@freebsd.org Delivered-To: freebsd-fs@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 2113F16A41C for ; Mon, 23 May 2005 16:44:21 +0000 (GMT) (envelope-from radix@dialatec.com) Received: from 5352E73D.cable.casema.nl (5352E73D.cable.casema.nl [83.82.231.61]) by mx1.FreeBSD.org (Postfix) with SMTP id 91D3D43D58 for ; Mon, 23 May 2005 16:44:19 +0000 (GMT) (envelope-from radix@dialatec.com) Received: from [91.101.67.129] (port=4293 helo=[grabs]) by 5352E73D.cable.casema.nl with esmtp id 8951128752rampage127078 for freebsd-fs@freebsd.org; Mon, 23 May 2005 18:44:27 +0200 Mime-Version: 1.0 (News mailer) Content-Transfer-Encoding: 7bit Message-Id: <90276101471.5017677209@5352E73D.cable.casema.nl> Content-Type: text/plain; charset=US-ASCII; format=flowed To: freebsd-fs@freebsd.org From: Florence Date: Mon, 23 May 2005 18:44:26 +0200 X-Mailer: News mailer 1.9 Subject: Our service is user-friendly, discreet and completely confidential 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, 23 May 2005 16:44:21 -0000 Every man must have a sex! MUST!!! http://Kigali.pilsforhealth.info/?galaxyxtvuyalderzsvhailstone The thing is that a great errrect1on is provided for you exactly when you want. From owner-freebsd-fs@FreeBSD.ORG Tue May 24 17:27:29 2005 Return-Path: X-Original-To: freebsd-fs@freebsd.org Delivered-To: freebsd-fs@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 3B09D16A41C for ; Tue, 24 May 2005 17:27:29 +0000 (GMT) (envelope-from paul@gromit.dlib.vt.edu) Received: from gromit.dlib.vt.edu (gromit.dlib.vt.edu [128.173.49.29]) by mx1.FreeBSD.org (Postfix) with ESMTP id D373E43D49 for ; Tue, 24 May 2005 17:27:26 +0000 (GMT) (envelope-from paul@gromit.dlib.vt.edu) Received: from zappa.Chelsea-Ct.Org (pool-151-199-7-31.ROA.east.verizon.net [151.199.7.31]) by gromit.dlib.vt.edu (8.13.3/8.13.3) with ESMTP id j4OHROt5071432 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK) for ; Tue, 24 May 2005 13:27:25 -0400 (EDT) (envelope-from paul@gromit.dlib.vt.edu) Received: from zappa.Chelsea-Ct.Org (localhost.Chelsea-Ct.Org [127.0.0.1]) by zappa.Chelsea-Ct.Org (8.13.3/8.13.3) with ESMTP id j4OHRJJH050106 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK) for ; Tue, 24 May 2005 13:27:19 -0400 (EDT) (envelope-from paul@gromit.dlib.vt.edu) Received: (from paul@localhost) by zappa.Chelsea-Ct.Org (8.13.3/8.13.3/Submit) id j4OHRJ7g050105 for freebsd-fs@freebsd.org; Tue, 24 May 2005 13:27:19 -0400 (EDT) (envelope-from paul@gromit.dlib.vt.edu) X-Authentication-Warning: zappa.Chelsea-Ct.Org: paul set sender to paul@gromit.dlib.vt.edu using -f From: Paul Mather To: freebsd-fs@freebsd.org Content-Type: text/plain Content-Transfer-Encoding: 7bit Date: Tue, 24 May 2005 13:27:18 -0400 Message-Id: <1116955638.48224.27.camel@zappa.Chelsea-Ct.Org> Mime-Version: 1.0 X-Mailer: Evolution 2.2.2 FreeBSD GNOME Team Port Subject: Recovering UFS2 content via Sleuthkit 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, 24 May 2005 17:27:29 -0000 Has anyone managed successfully to recover deleted file content using, say, Sleuthkit, or is deleted UFS2 content recovery not feasible (aside from sifting manually with a disk sector editor)? I tried Sleuthkit from the ports collection, and although I can find deleted content using it, it's not possible to recover that content because too much important information has been lost from the inode: specifically, although information like the owner and timestamp information appears to be preserved, vital data such as the size, direct blocks, etc. are all zeroed, rendering the deleted content unreachable (or, rather, reducing the problem back to a manual search). So, am I right in thinking that even if the inodes and blocks belonging to a deleted file have not yet been reallocated or used again, it's still not feasible to recover the deleted content easily because of the data loss inflicted upon the deleted file's inode(s)? In other words, that the only data recovery possible is via manual means (searching for signatures and trying to piece together fragments)? Also, I wonder why some, but not all, information is scrubbed when a file becomes deleted (especially information in the inode). Cheers, Paul. PS: Please Cc: me on replies, as I'm not subscribed to this list. -- e-mail: paul@gromit.dlib.vt.edu "Without music to decorate it, time is just a bunch of boring production deadlines or dates by which bills must be paid." --- Frank Vincent Zappa From owner-freebsd-fs@FreeBSD.ORG Tue May 24 18:43:01 2005 Return-Path: X-Original-To: freebsd-fs@freebsd.org Delivered-To: freebsd-fs@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 7CD5816A41C for ; Tue, 24 May 2005 18:43:01 +0000 (GMT) (envelope-from bv@bilver.wjv.com) Received: from wjv.com (fl-65-40-24-38.sta.sprint-hsd.net [65.40.24.38]) by mx1.FreeBSD.org (Postfix) with ESMTP id EF27C43D4C for ; Tue, 24 May 2005 18:43:00 +0000 (GMT) (envelope-from bv@bilver.wjv.com) Received: from bilver.wjv.com (localhost.wjv.com [127.0.0.1]) by wjv.com (8.12.11/8.13.1) with ESMTP id j4OIgvk8085290; Tue, 24 May 2005 14:42:58 -0400 (EDT) (envelope-from bv@bilver.wjv.com) Received: (from bv@localhost) by bilver.wjv.com (8.12.11/8.13.1/Submit) id j4OIgvGY085289; Tue, 24 May 2005 14:42:57 -0400 (EDT) (envelope-from bv) Date: Tue, 24 May 2005 14:42:57 -0400 From: Bill Vermillion To: Paul Mather Message-ID: <20050524184257.GB84311@wjv.com> References: <1116955638.48224.27.camel@zappa.Chelsea-Ct.Org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <1116955638.48224.27.camel@zappa.Chelsea-Ct.Org> Organization: W.J.Vermillion / Orlando - Winter Park ReplyTo: bv@wjv.com User-Agent: Mutt/1.5.6i X-Spam-Status: No, score=-2.8 required=5.0 tests=ALL_TRUSTED autolearn=failed version=3.0.3 X-Spam-Checker-Version: SpamAssassin 3.0.3 (2005-04-27) on bilver.wjv.com Cc: freebsd-fs@freebsd.org Subject: Re: Recovering UFS2 content via Sleuthkit X-BeenThere: freebsd-fs@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: bv@wjv.com List-Id: Filesystems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 24 May 2005 18:43:01 -0000 While humming that old rock song Yackety Yacc - Dont Awk Back Paul Mather sang or SED something like this: > Has anyone managed successfully to recover deleted file content > using, say, Sleuthkit, or is deleted UFS2 content recovery > not feasible (aside from sifting manually with a disk sector > editor)? I've not used Sleuthkit but I've managed to recover files using TCT - The Coroners Tookkit and the program 'lasarus' in conjunction with 'unrm'. > I tried Sleuthkit from the ports collection, and although I can > find deleted content using it, it's not possible to recover > that content because too much important information has been > lost from the inode: specifically, although information like > the owner and timestamp information appears to be preserved, > vital data such as the size, direct blocks, etc. are all zeroed, > rendering the deleted content unreachable (or, rather, reducing > the problem back to a manual search). > So, am I right in thinking that even if the inodes and blocks > belonging to a deleted file have not yet been reallocated or > used again, it's still not feasible to recover the deleted > content easily because of the data loss inflicted upon the > deleted file's inode(s)? In other words, that the only data > recovery possible is via manual means (searching for signatures > and trying to piece together fragments)? 'lazarus' has options to build files or build an html structure. 'unrm' is preferable to use over 'dd' because you use it to search the disk only for unallocated blocks. What you will often find in the recovered files are parts of two files at times, or only part of one large file. This is because the 'unrm' goes block by block through the drive, and files are not neccesarily contiguous. When I ran 'unrm' and 'lazarus' after stupidly not checking a command line [I accidentally remove files like this about every 6 or 8 years :-( ] I saved the output of the unrm to another partition, then ran lazarus to parse those pieces found by 'unrm'. Then when I got the whole segment done, I just moved that entire tree into my XP machine and used the 'search' utility to look for strings. My problem was that I didn't notice the missing files for about a week and I do run a news machine so I dinged a lot of files. Nothing is easy when it comes to recovering lost files. But you learn more about the system, and more importantly it reinforces your checking to keep from doing this again - hopefully. > Also, I wonder why some, but not all, information is scrubbed when a > file becomes deleted (especially information in the inode). Probably for performance problems. There has been talk about buildding an FS that will zero blocks when you remove the indoes, and in that case you will never recover anything. An 'rm' just essentially frees up the inodes, and doesn't do a thing with the on-disk blocks. > PS: Please Cc: me on replies, as I'm not subscribed to this list. Done. Best of luck on your attempts. 'tis painful and I've done it. If you run lazarus to output html you may be surprised to find what else lurrks on your disk that you thought you had gotten rid of. Bill > "Without music to decorate it, time is just a bunch of boring production > deadlines or dates by which bills must be paid." > --- Frank Vincent Zappa I'll go along with those sediments too. Bill -- Bill Vermillion - bv @ wjv . com From owner-freebsd-fs@FreeBSD.ORG Tue May 24 20:12:03 2005 Return-Path: X-Original-To: freebsd-fs@freebsd.org Delivered-To: freebsd-fs@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id B77E716A41C for ; Tue, 24 May 2005 20:12:03 +0000 (GMT) (envelope-from paul@gromit.dlib.vt.edu) Received: from gromit.dlib.vt.edu (gromit.dlib.vt.edu [128.173.49.29]) by mx1.FreeBSD.org (Postfix) with ESMTP id 5CC0143D49 for ; Tue, 24 May 2005 20:12:03 +0000 (GMT) (envelope-from paul@gromit.dlib.vt.edu) Received: from zappa.Chelsea-Ct.Org (pool-151-199-7-31.ROA.east.verizon.net [151.199.7.31]) by gromit.dlib.vt.edu (8.13.3/8.13.3) with ESMTP id j4OKBvsJ071875 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Tue, 24 May 2005 16:12:02 -0400 (EDT) (envelope-from paul@gromit.dlib.vt.edu) Received: from zappa.Chelsea-Ct.Org (localhost.Chelsea-Ct.Org [127.0.0.1]) by zappa.Chelsea-Ct.Org (8.13.3/8.13.3) with ESMTP id j4OKBnwo050586 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Tue, 24 May 2005 16:11:49 -0400 (EDT) (envelope-from paul@gromit.dlib.vt.edu) Received: (from paul@localhost) by zappa.Chelsea-Ct.Org (8.13.3/8.13.3/Submit) id j4OKBm1o050585; Tue, 24 May 2005 16:11:48 -0400 (EDT) (envelope-from paul@gromit.dlib.vt.edu) X-Authentication-Warning: zappa.Chelsea-Ct.Org: paul set sender to paul@gromit.dlib.vt.edu using -f From: Paul Mather To: bv@wjv.com In-Reply-To: <20050524184257.GB84311@wjv.com> References: <1116955638.48224.27.camel@zappa.Chelsea-Ct.Org> <20050524184257.GB84311@wjv.com> Content-Type: text/plain Content-Transfer-Encoding: 7bit Date: Tue, 24 May 2005 16:11:48 -0400 Message-Id: <1116965508.50272.24.camel@zappa.Chelsea-Ct.Org> Mime-Version: 1.0 X-Mailer: Evolution 2.2.2 FreeBSD GNOME Team Port Cc: freebsd-fs@freebsd.org Subject: Re: Recovering UFS2 content via Sleuthkit 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, 24 May 2005 20:12:03 -0000 On Tue, 2005-05-24 at 14:42 -0400, Bill Vermillion wrote: > > Has anyone managed successfully to recover deleted file content > > using, say, Sleuthkit, or is deleted UFS2 content recovery > > not feasible (aside from sifting manually with a disk sector > > editor)? > > I've not used Sleuthkit but I've managed to recover files > using TCT - The Coroners Tookkit and the program 'lasarus' in > conjunction with 'unrm'. Thanks for the suggestion. Unfortunately, my desktop system runs FreeBSD 6.0-CURRENT, and I discovered the following when trying to build TCT from ports: ===> tct-1.14 is marked as broken: Does not build on FreeBSD >= 6.x. I do have a 4.11-STABLE system, and did build the TCT port there, mainly to have a look at the documentation. Does unrm understand UFS2? I can only see references to UFS. > > I tried Sleuthkit from the ports collection, and although I can > > find deleted content using it, it's not possible to recover > > that content because too much important information has been > > lost from the inode: specifically, although information like > > the owner and timestamp information appears to be preserved, > > vital data such as the size, direct blocks, etc. are all zeroed, > > rendering the deleted content unreachable (or, rather, reducing > > the problem back to a manual search). > > > So, am I right in thinking that even if the inodes and blocks > > belonging to a deleted file have not yet been reallocated or > > used again, it's still not feasible to recover the deleted > > content easily because of the data loss inflicted upon the > > deleted file's inode(s)? In other words, that the only data > > recovery possible is via manual means (searching for signatures > > and trying to piece together fragments)? > > 'lazarus' has options to build files or build an html structure. > 'unrm' is preferable to use over 'dd' because you use it to > search the disk only for unallocated blocks. > > What you will often find in the recovered files are parts of > two files at times, or only part of one large file. This is because > the 'unrm' goes block by block through the drive, and files are not > neccesarily contiguous. > > When I ran 'unrm' and 'lazarus' after stupidly not checking a > command line [I accidentally remove files like this about every 6 > or 8 years :-( ] I saved the output of the unrm to another > partition, then ran lazarus to parse those pieces found by 'unrm'. > Then when I got the whole segment done, I just moved that entire > tree into my XP machine and used the 'search' utility to look for > strings. Looking at lazarus, it seems like it is trying to semi-automate a manual search/classification of data blocks. Is this a consequence of what I observed originally (i.e., too much vital information is scrubbed in the inode when a file is deleted, so, even if the inode[s] and data blocks have not been reallocated, there's still no direct linkage information for data recovery software to chase)? In my case, I'll probably not bother with lazarus. According to Sleuthkit, the deleted content seems to consist mainly of some PDF files and some multimedia files (FLAC, SHN, AVI, and MPG). Unfortunately, these would seem to be poor candidates for manual inspection recovery, because it's hard to see what is a valid part of the file, and whether everything is in the correct order. With the multimedia files, in particular, these are likely to be large and hence much more likely to be non-contiguously laid out. > Nothing is easy when it comes to recovering lost files. But you > learn more about the system, and more importantly it reinforces > your checking to keep from doing this again - hopefully. In my case, it was a matter of executing the right command in the wrong directory too late at night on too little sleep. ;-) I did manage to ctrl-c the command fairly quickly, when I realised the Awful Truth of what was happening. :-) In retrospect, I should probably have bashed the reset button before SoftUpdates had a chance to start committing things to disk. :-) > > Also, I wonder why some, but not all, information is scrubbed when a > > file becomes deleted (especially information in the inode). > > Probably for performance problems. There has been talk about > buildding an FS that will zero blocks when you remove the indoes, > and in that case you will never recover anything. An 'rm' just > essentially frees up the inodes, and doesn't do a thing with the > on-disk blocks. I can understand not scrubbing the on-disk blocks (as you say, for performance reasons), but it seemed curious that only some parts of the dinode appeared to be scrubbed, because it's all going to be written back to disk anyway (so why not scrub it all?). (Perhaps it's just a sadistic way of mocking those who would attempt data recovery: a sort of "you're close, but not close enough..." [cue echoing mocking laughter, et al.] :-)) > Best of luck on your attempts. 'tis painful and I've done it. > If you run lazarus to output html you may be surprised to find what > else lurrks on your disk that you thought you had gotten rid of. Sleuthkit was very revealing when it came to finding deleted content (and Autopsy makes browsing very convenient). It just seemed no good for actually recovering it, at least as far as I could tell. It does support UFS2, though. Thanks for the help and advice! Cheers, Paul. -- e-mail: paul@gromit.dlib.vt.edu "Without music to decorate it, time is just a bunch of boring production deadlines or dates by which bills must be paid." --- Frank Vincent Zappa From owner-freebsd-fs@FreeBSD.ORG Wed May 25 15:15:42 2005 Return-Path: X-Original-To: freebsd-fs@freebsd.org Delivered-To: freebsd-fs@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 239BF16A41C for ; Wed, 25 May 2005 15:15:42 +0000 (GMT) (envelope-from clive@tongi.org) Received: from drop.bsdchat.com (drop.bsdchat.com [209.237.225.38]) by mx1.FreeBSD.org (Postfix) with ESMTP id E767743D1D for ; Wed, 25 May 2005 15:15:41 +0000 (GMT) (envelope-from clive@tongi.org) Received: from CARTIER (drag.bsdchat.com [209.237.225.37]) by drop.bsdchat.com (8.13.3/8.13.3) with SMTP id j4PFFZUU010415; Wed, 25 May 2005 15:15:36 GMT (envelope-from clive@tongi.org) Received: (nullmailer pid 1334 invoked by uid 1000); Wed, 25 May 2005 15:15:05 -0000 Date: Wed, 25 May 2005 23:15:05 +0800 From: Clive Lin To: Herv? Kergourlay Message-ID: <20050525151505.GA1287@tongi.org> References: <427F491C.4090501@club-internet.fr> <427F9404.8060509@samsco.org> <42834982.40302@club-internet.fr> <42834CF9.6060301@atempo.com> <20050522092926.GA1042@tongi.org> <4291C50B.1090505@atempo.com> Mime-Version: 1.0 Content-Type: text/plain; charset=big5 Content-Disposition: inline Content-Transfer-Encoding: quoted-printable In-Reply-To: <4291C50B.1090505@atempo.com> X-PGP-key: http://pgp.mit.edu:11371/pks/lookup?op=get&search=0xA008C03E User-Agent: Mutt/1.5.9i X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-1.6 (drop.bsdchat.com [209.237.225.38]); Wed, 25 May 2005 15:15:37 +0000 (UTC) Cc: freebsd-fs@freebsd.org Subject: Re: setfacl -d 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, 25 May 2005 15:15:42 -0000 On Mon, May 23, 2005 at 01:56:59PM +0200, Herv? Kergourlay wrote: > Clive Lin a =E9crit : > > For freshly created directory, you have to do 'setfacl -m ...' first. > >$ mkdir aclTest > >$ setfacl -d -m u:clive:rwx aclTest > >setfacl: acl_calc_mask() failed: Invalid argument > >setfacl: failed to set ACL mask on aclTest > >$ setfacl -m u:clive:rwx aclTest > >$ getfacl aclTest | setfacl -d -b -n -M - aclTest > >$ getfacl -d aclTest|grep clive > >user:clive:rwx >=20 > it's effectively working > but it's a very complex method, how can the standard user knows that ? Perhaps it could be documented in the setfacl(1) EXAMPLES section :> --=20 Clive Tong-I Lin | http://tongi.org | PGP KeyID: A008C03E From owner-freebsd-fs@FreeBSD.ORG Wed May 25 15:22:35 2005 Return-Path: X-Original-To: freebsd-fs@freebsd.org Delivered-To: freebsd-fs@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 357D616A41C for ; Wed, 25 May 2005 15:22:35 +0000 (GMT) (envelope-from herve.kergourlay@atempo.com) Received: from ds9.atempo.com (ds9.atempo.com [212.157.146.98]) by mx1.FreeBSD.org (Postfix) with ESMTP id 93ED143D4C for ; Wed, 25 May 2005 15:22:31 +0000 (GMT) (envelope-from herve.kergourlay@atempo.com) Received: from ds9.atempo.com (localhost.localdomain [127.0.0.1]) by localhost.atempo.com (Postfix) with ESMTP id 608412FD29; Wed, 25 May 2005 17:22:23 +0200 (CEST) Received: from atempo.com (unknown [172.16.15.140])by ds9.atempo.com (Postfix) with ESMTP id 514D32FD16; Wed, 25 May 2005 17:22:23 +0200 (CEST) Received: from [192.168.2.108] (aragorn.vannes.quadratec.fr [192.168.2.108])by atempo.com (Postfix) with ESMTP id 01B5B1E326F; Wed, 25 May 2005 17:22:22 +0200 (CEST) Message-ID: <4294982E.5000501@atempo.com> Date: Wed, 25 May 2005 17:22:22 +0200 From: =?UTF-8?B?SGVydsOpIEtlcmdvdXJsYXk=?= User-Agent: Mozilla Thunderbird 1.0 (Windows/20041206) X-Accept-Language: fr, en MIME-Version: 1.0 To: Clive Lin References: <427F491C.4090501@club-internet.fr> <427F9404.8060509@samsco.org> <42834982.40302@club-internet.fr> <42834CF9.6060301@atempo.com> <20050522092926.GA1042@tongi.org> <4291C50B.1090505@atempo.com> <20050525151505.GA1287@tongi.org> In-Reply-To: <20050525151505.GA1287@tongi.org> X-Enigmail-Version: 0.90.0.0 X-Enigmail-Supports: pgp-inline, pgp-mime Content-Type: multipart/mixed; boundary=------------040805010206060009020002 X-imss-version: 2.025 X-imss-result: Passed X-imss-approveListMatch: *@atempo.com X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Cc: freebsd-fs@freebsd.org Subject: Re: setfacl -d 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, 25 May 2005 15:22:35 -0000 This is a multi-part message in MIME format. --------------040805010206060009020002 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit Clive Lin a écrit : >On Mon, May 23, 2005 at 01:56:59PM +0200, Herv? Kergourlay wrote: > > >>Clive Lin a 嶰rit : >> >> >>> For freshly created directory, you have to do 'setfacl -m ...' first. >>>$ mkdir aclTest >>>$ setfacl -d -m u:clive:rwx aclTest >>>setfacl: acl_calc_mask() failed: Invalid argument >>>setfacl: failed to set ACL mask on aclTest >>>$ setfacl -m u:clive:rwx aclTest >>>$ getfacl aclTest | setfacl -d -b -n -M - aclTest >>>$ getfacl -d aclTest|grep clive >>>user:clive:rwx >>> >>> >>it's effectively working >>but it's a very complex method, how can the standard user knows that ? >> >> > >Perhaps it could be documented in the setfacl(1) EXAMPLES section :> > > > the best will be to have the -d option full usable bye hervé --------------040805010206060009020002-- From owner-freebsd-fs@FreeBSD.ORG Fri May 27 12:27:44 2005 Return-Path: X-Original-To: freebsd-fs@freebsd.org Delivered-To: freebsd-fs@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 7A8DB16A41C; Fri, 27 May 2005 12:27:44 +0000 (GMT) (envelope-from dom@goodforbusiness.co.uk) Received: from mail.helenmarks.co.uk (mail.helenmarks.co.uk [82.68.196.22]) by mx1.FreeBSD.org (Postfix) with ESMTP id DC76143D1D; Fri, 27 May 2005 12:27:43 +0000 (GMT) (envelope-from dom@goodforbusiness.co.uk) Received: from localhost (localhost [127.0.0.1]) by mail.helenmarks.co.uk (Postfix) with ESMTP id 4F094222404; Fri, 27 May 2005 13:27:42 +0100 (BST) Received: from mail.helenmarks.co.uk ([127.0.0.1]) by localhost (mail.helenmarks.co.uk [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 60060-06; Fri, 27 May 2005 13:27:37 +0100 (BST) Received: from egg.helenmarks.co.uk (egg.helenmarks.co.uk [192.168.15.3]) by mail.helenmarks.co.uk (Postfix) with ESMTP id 5F560222403; Fri, 27 May 2005 13:27:37 +0100 (BST) From: Dominic Marks Organization: GoodforBusiness.co.uk To: bug-followup@FreeBSD.org, banhalmi@field.hu, freebsd-fs@freebsd.org Date: Fri, 27 May 2005 13:28:57 +0100 User-Agent: KMail/1.8 MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200505271328.58072.dom@goodforbusiness.co.uk> X-Virus-Scanned: By ClamAV 0.80 Cc: Subject: Re: i386/68719: [usb] USB 2.0 mobil rack+ fat32 performance 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: Fri, 27 May 2005 12:27:44 -0000 (Posted to freebsd-fs as the PR is assigned to freebsd-usb@, but it seems to be more related to the msdos filesystem than the USB system so perhaps it should be reassigned?) I've been evaluating the performance of some usb2 hard discs with FreeBSD and I found this PR (68719). The submitter is correct that performance with msdosfs is severely limited. I tested a 'LaCie' USB2 disc: da0 at umass-sim0 bus 0 target 0 lun 0 da0: Fixed Direct Access SCSI-2 device da0: 40.000MB/s transfers da0: 239372MB (490234752 512 byte sectors: 255H 63S/T 30515C) egg# diskinfo -t da0 ... Seek times: Full stroke: 250 iter in 5.271879 sec = 21.088 msec Half stroke: 250 iter in 4.055049 sec = 16.220 msec Quarter stroke: 500 iter in 6.696545 sec = 13.393 msec Short forward: 400 iter in 2.316910 sec = 5.792 msec Short backward: 400 iter in 2.052681 sec = 5.132 msec Seq outer: 2048 iter in 1.574044 sec = 0.769 msec Seq inner: 2048 iter in 1.576574 sec = 0.770 msec Transfer rates: outside: 102400 kbytes in 3.445316 sec = 29722 kbytes/sec middle: 102400 kbytes in 3.441593 sec = 29754 kbytes/sec inside: 102400 kbytes in 3.435809 sec = 29804 kbytes/sec I used 10GB chunks of data to test the USB disc. Each test used a different 10GB of data to avoid caching distorting results. I made the following measurements with both UFS2 and FAT32. 1. Local disc copy from a new SATA-150 disc. 2. Ftp copy over a local 100Mbit network from a server with a SATA-150 disc. 3. Create a zero-file using dd to test simple write performance. Client with attached USB disc: P4 2.6Ghz 768MB DDR, if_fxp, 1x ATA-100 disc Server used for FTP: Celeron 2.4GHz 1.5GB DDR, if_em, 4x SATA-150 discs. Both the client and server are running FreeBSD 5.4-STABLE built at Thu May 26 22:52:15 BST 2005. In test 1 I could not achieve any better than 5.1MB/s on an msdosfs filesystem. Using UFS2 and softupdates a transfer rate of 22~25MB/s was possible. Both test data sets were copied from the systems ATA-100 disc. In both tests at these peaks gstat reports the device is 100% busy. A snapshot from gstat(8) during test 1. da0s1 is the fat32 filesystem. dT: 0.501 flag_I 500000us sizeof 240 i -1 L(q) ops/s r/s kBps ms/r w/s kBps ms/w %busy Name 2 90 90 3363 5.2 0 0 0.0 38.2| ad0 2 90 90 3363 5.2 0 0 0.0 38.4| ad0s1 ... 2 90 90 3363 5.3 0 0 0.0 39.0| ad0s1g 96 1295 2 8 163.9 1293 5170 141.6 99.8| da0 96 1295 2 8 163.9 1293 5170 143.1 99.9| da0s1 In test 2 again the msdosfs filesystem could not achieve higher than 5MB/s. With UFS2 the limit of the network was reached before the limit of the USB2 bus so the transfer was limited to 10.5MB/s average. During this period gstat reported about 35-45% activity on the device which matches up as I would have expected. I managed to improve the performance in these results a little by upping MAXPHYS to 256, and then to 512 on the client. Going from 128 to 256 improved the diskinto -t transfer rates by about 3MB/s increasing it to 512 seemed to have no further benefit. Enabling polling for the fxp interface helped as well by reducing the interrupt rate from ~8k/s to 2k/s during the second test. Finally, I used dd to test just the filesystem-write. ufs2: egg# dd if=/dev/zero of=/mnt/file.test bs=64k count=10000 10000+0 records in 10000+0 records out 655360000 bytes transferred in 25.093943 secs (26116262 bytes/sec) And from gstat during the `dd': dT: 0.501 flag_I 500000us sizeof 240 i -1 L(q) ops/s r/s kBps ms/r w/s kBps ms/w %busy Name ... 2 50 2 32 47.8 48 24510 45.7 97.8| da0 2 50 2 32 47.9 48 24510 45.7 97.8| da0s1 msdosfs: egg# dd if=/dev/zero of=/mnt/file2.test bs=64k count=10000 10000+0 records in 10000+0 records out 655360000 bytes transferred in 123.332992 secs (5313744 bytes/sec) gstat: dT: 0.501 flag_I 500000us sizeof 240 i -1 L(q) ops/s r/s kBps ms/r w/s kBps ms/w %busy Name ... 163 1314 0 0 0.0 1314 5258 145.4 100.0| da0 163 1314 0 0 0.0 1314 5258 146.5 100.0| da0s1 The ECHI controller is: ehci0: mem 0xffa80800-0xffa80bff irq 23 at device 29.7 on pci0 usb4: EHCI version 1.0 usb4: companion controllers, 2 ports each: usb0 usb1 usb2 usb3 usb4: on ehci0 usb4: USB revision 2.0 uhub4: Intel EHCI root hub, class 9/0, rev 2.00/1.00, addr 1 uhub4: 8 ports with 8 removable, self powered I have not made any tests of read performance but from looking at the results I do not expect that it will be significantly better than write performance. I may do some when I get more time to investigate and follow up if the results are unexpected. Hopefully this will generate some interest in the problem, it is beyond my time and expertise but it would be very nice to be able to access MS-DOS formatted filesystems at a reasonable speed! Thank you, -- Dominic GoodforBusiness.co.uk I.T. Services for SMEs in the UK. From owner-freebsd-fs@FreeBSD.ORG Sat May 28 10:37:12 2005 Return-Path: X-Original-To: freebsd-fs@FreeBSD.org Delivered-To: freebsd-fs@FreeBSD.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 7098A16A41C; Sat, 28 May 2005 10:37:12 +0000 (GMT) (envelope-from bde@zeta.org.au) Received: from mailout2.pacific.net.au (mailout2.pacific.net.au [61.8.0.85]) by mx1.FreeBSD.org (Postfix) with ESMTP id E806543D48; Sat, 28 May 2005 10:37:11 +0000 (GMT) (envelope-from bde@zeta.org.au) Received: from mailproxy1.pacific.net.au (mailproxy1.pacific.net.au [61.8.0.86]) by mailout2.pacific.net.au (8.12.3/8.12.3/Debian-7.1) with ESMTP id j4SAaxkG017884; Sat, 28 May 2005 20:36:59 +1000 Received: from epsplex.bde.org (katana.zip.com.au [61.8.7.246]) by mailproxy1.pacific.net.au (8.12.3/8.12.3/Debian-7.1) with ESMTP id j4SAasqB006047; Sat, 28 May 2005 20:36:56 +1000 Date: Sat, 28 May 2005 20:36:55 +1000 (EST) From: Bruce Evans X-X-Sender: bde@epsplex.bde.org To: Dominic Marks In-Reply-To: <200505271328.58072.dom@goodforbusiness.co.uk> Message-ID: <20050528194126.W3563@epsplex.bde.org> References: <200505271328.58072.dom@goodforbusiness.co.uk> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Cc: freebsd-fs@FreeBSD.org, freebsd-gnats-submit@FreeBSD.org, banhalmi@field.hu Subject: Re: i386/68719: [usb] USB 2.0 mobil rack+ fat32 performance 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: Sat, 28 May 2005 10:37:12 -0000 On Fri, 27 May 2005, Dominic Marks wrote: > (Posted to freebsd-fs as the PR is assigned to freebsd-usb@, but it seems to > be more related to the msdos filesystem than the USB system so perhaps it > should be reassigned?) It should be. It is even less i386-specific than usb-specific. > I've been evaluating the performance of some usb2 hard discs with FreeBSD and > I found this PR (68719). The submitter is correct that performance with > msdosfs is severely limited. > > I tested a 'LaCie' USB2 disc: > ... > In test 1 I could not achieve any better than 5.1MB/s on an msdosfs > filesystem. Using UFS2 and softupdates a transfer rate of 22~25MB/s was > possible. Both test data sets were copied from the systems ATA-100 disc. In > both tests at these peaks gstat reports the device is 100% busy. I use the following to improve transfer rates for msdosfs. The patch is for an old version so it might not apply directly. %%% Index: msdosfs_vnops.c =================================================================== RCS file: /home/ncvs/src/sys/fs/msdosfs/msdosfs_vnops.c,v retrieving revision 1.147 diff -u -2 -r1.147 msdosfs_vnops.c --- msdosfs_vnops.c 4 Feb 2004 21:52:53 -0000 1.147 +++ msdosfs_vnops.c 22 Feb 2004 07:27:15 -0000 @@ -608,4 +622,5 @@ int error = 0; u_long count; + int seqcount; daddr_t bn, lastcn; struct buf *bp; @@ -693,4 +714,5 @@ lastcn = de_clcount(pmp, osize) - 1; + seqcount = ioflag >> IO_SEQSHIFT; do { if (de_cluster(pmp, uio->uio_offset) > lastcn) { @@ -718,5 +740,5 @@ */ bp = getblk(thisvp, bn, pmp->pm_bpcluster, 0, 0, 0); - clrbuf(bp); + vfs_bio_clrbuf(bp); /* * Do the bmap now, since pcbmap needs buffers @@ -767,11 +789,19 @@ * without delay. Otherwise do a delayed write because we * may want to write somemore into the block later. + * XXX comment not updated with code. */ + if ((vp->v_mount->mnt_flag & MNT_NOCLUSTERW) == 0) + bp->b_flags |= B_CLUSTEROK; if (ioflag & IO_SYNC) - (void) bwrite(bp); - else if (n + croffset == pmp->pm_bpcluster) + (void)bwrite(bp); + else if (vm_page_count_severe() || buf_dirty_count_severe()) bawrite(bp); - else - bdwrite(bp); + else if (n + croffset == pmp->pm_bpcluster) { + if ((vp->v_mount->mnt_flag & MNT_NOCLUSTERW) == 0) + cluster_write(bp, dep->de_FileSize, seqcount); + else + bawrite(bp); + } else + bdwrite(bp); dep->de_flag |= DE_UPDATE; } while (error == 0 && uio->uio_resid > 0); %%% Notes: - The xxx_count_severe() stuff doesn't work quite right and was observed to work especially badly for msdosfs in some configurations. IIRC, only configurations with a tiny block size (e.g., 512 bytes) showed the problem, and the problem is more likely to be with tiny block sizes actually exercising the "severe" case than with msdosfs or with the tiny block sizes themselves. The behaviour was apparently that when a severe page or buf shortage develops, the above handling makes the problem worse by using bawrite() instead of cluster_write(). Falling back to bawrite() may have made the resource shortage non-fatal, but it made the resource shortage last much longer since bawrite() was much slower, even on the reasonable fast ATA drive that I was testing on. - Using cluster_write() in the above is not essential. bdwrite() works almost as well, or perhaps even better than cluster_write() provided write clustering is enabled by setting B_CLUSTEROK, since when this flag is set the delayed writes are clustered when they are done physically. > I have not made any tests of read performance but from looking at the results > I do not expect that it will be significantly better than write performance. > I may do some when I get more time to investigate and follow up if the > results are unexpected. Try it. I would expect read performance to be much better. If not, don't bother trying the above patch. msdosfs uses read-ahead for read(), and this seems to work well so I haven't even tried changing it to use read clustering (the above only changes it to use write clustering). This may depend on the drive doing read caching and not handling small block sizes too badly. I mostly use ATA drives that have these properties. Writing tinygrams tends to have a relatively higher cost because write caching is not enabled so clustering can only be done by the OS. > Hopefully this will generate some interest in the problem, it is beyond my > time and expertise but it would be very nice to be able to access MS-DOS > formatted filesystems at a reasonable speed! Some other changes are needed for general use at a reasonable speed: - use VMIO for metadata. - don't use pessimal block allocation. The current allocator gives large inter-file fragmentation by attempting to minimise intra-file fragmentation, and when the file system becomes just 1/N full the attempt backfires and gives intra-file fragmentation too (files with more than N clusters are very likely to be fragmented). Bruce From owner-freebsd-fs@FreeBSD.ORG Sat May 28 11:12:26 2005 Return-Path: X-Original-To: freebsd-fs@FreeBSD.org Delivered-To: freebsd-fs@FreeBSD.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 2145416A41C; Sat, 28 May 2005 11:12:26 +0000 (GMT) (envelope-from dom@goodforbusiness.co.uk) Received: from mail.helenmarks.co.uk (mail.helenmarks.co.uk [82.68.196.22]) by mx1.FreeBSD.org (Postfix) with ESMTP id 6602943D48; Sat, 28 May 2005 11:12:25 +0000 (GMT) (envelope-from dom@goodforbusiness.co.uk) Received: from localhost (localhost [127.0.0.1]) by mail.helenmarks.co.uk (Postfix) with ESMTP id 324BA222404; Sat, 28 May 2005 12:12:22 +0100 (BST) Received: from mail.helenmarks.co.uk ([127.0.0.1]) by localhost (mail.helenmarks.co.uk [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 79244-07; Sat, 28 May 2005 12:12:19 +0100 (BST) Received: from egg.helenmarks.co.uk (egg.helenmarks.co.uk [192.168.15.3]) by mail.helenmarks.co.uk (Postfix) with ESMTP id 08E1C222403; Sat, 28 May 2005 12:12:19 +0100 (BST) From: Dominic Marks Organization: GoodforBusiness.co.uk To: Bruce Evans Date: Sat, 28 May 2005 12:13:41 +0100 User-Agent: KMail/1.8 References: <200505271328.58072.dom@goodforbusiness.co.uk> <20050528194126.W3563@epsplex.bde.org> In-Reply-To: <20050528194126.W3563@epsplex.bde.org> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200505281213.42118.dom@goodforbusiness.co.uk> X-Virus-Scanned: By ClamAV 0.80 Cc: freebsd-fs@FreeBSD.org, freebsd-gnats-submit@FreeBSD.org, banhalmi@field.hu Subject: Re: i386/68719: [usb] USB 2.0 mobil rack+ fat32 performance 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: Sat, 28 May 2005 11:12:26 -0000 On Saturday 28 May 2005 11:36, Bruce Evans wrote: > On Fri, 27 May 2005, Dominic Marks wrote: > > (Posted to freebsd-fs as the PR is assigned to freebsd-usb@, but it seems > > to be more related to the msdos filesystem than the USB system so perhaps > > it should be reassigned?) > > It should be. It is even less i386-specific than usb-specific. > > > I've been evaluating the performance of some usb2 hard discs with FreeBSD > > and I found this PR (68719). The submitter is correct that performance > > with msdosfs is severely limited. > > > > I tested a 'LaCie' USB2 disc: > > ... > > In test 1 I could not achieve any better than 5.1MB/s on an msdosfs > > filesystem. Using UFS2 and softupdates a transfer rate of 22~25MB/s was > > possible. Both test data sets were copied from the systems ATA-100 disc. > > In both tests at these peaks gstat reports the device is 100% busy. > > I use the following to improve transfer rates for msdosfs. The patch is > for an old version so it might not apply directly. > > %%% > Index: msdosfs_vnops.c > =================================================================== > RCS file: /home/ncvs/src/sys/fs/msdosfs/msdosfs_vnops.c,v > retrieving revision 1.147 > diff -u -2 -r1.147 msdosfs_vnops.c > --- msdosfs_vnops.c 4 Feb 2004 21:52:53 -0000 1.147 > +++ msdosfs_vnops.c 22 Feb 2004 07:27:15 -0000 > @@ -608,4 +622,5 @@ > int error = 0; > u_long count; > + int seqcount; > daddr_t bn, lastcn; > struct buf *bp; > @@ -693,4 +714,5 @@ > lastcn = de_clcount(pmp, osize) - 1; > > + seqcount = ioflag >> IO_SEQSHIFT; > do { > if (de_cluster(pmp, uio->uio_offset) > lastcn) { > @@ -718,5 +740,5 @@ > */ > bp = getblk(thisvp, bn, pmp->pm_bpcluster, 0, 0, 0); > - clrbuf(bp); > + vfs_bio_clrbuf(bp); > /* > * Do the bmap now, since pcbmap needs buffers > @@ -767,11 +789,19 @@ > * without delay. Otherwise do a delayed write because we > * may want to write somemore into the block later. > + * XXX comment not updated with code. > */ > + if ((vp->v_mount->mnt_flag & MNT_NOCLUSTERW) == 0) > + bp->b_flags |= B_CLUSTEROK; > if (ioflag & IO_SYNC) > - (void) bwrite(bp); > - else if (n + croffset == pmp->pm_bpcluster) > + (void)bwrite(bp); > + else if (vm_page_count_severe() || buf_dirty_count_severe()) > bawrite(bp); > - else > - bdwrite(bp); > + else if (n + croffset == pmp->pm_bpcluster) { > + if ((vp->v_mount->mnt_flag & MNT_NOCLUSTERW) == 0) > + cluster_write(bp, dep->de_FileSize, seqcount); > + else > + bawrite(bp); > + } else > + bdwrite(bp); > dep->de_flag |= DE_UPDATE; > } while (error == 0 && uio->uio_resid > 0); > %%% Thanks! I'll try my three tests again with this patch. > Notes: > - The xxx_count_severe() stuff doesn't work quite right and was observed > to work especially badly for msdosfs in some configurations. IIRC, > only configurations with a tiny block size (e.g., 512 bytes) showed > the problem, and the problem is more likely to be with tiny block sizes > actually exercising the "severe" case than with msdosfs or with the > tiny block sizes themselves. The behaviour was apparently that when > a severe page or buf shortage develops, the above handling makes the > problem worse by using bawrite() instead of cluster_write(). Falling > back to bawrite() may have made the resource shortage non-fatal, but > it made the resource shortage last much longer since bawrite() was much > slower, even on the reasonable fast ATA drive that I was testing on. > - Using cluster_write() in the above is not essential. bdwrite() works > almost as well, or perhaps even better than cluster_write() provided > write clustering is enabled by setting B_CLUSTEROK, since when this > flag is set the delayed writes are clustered when they are done > physically. > > > I have not made any tests of read performance but from looking at the > > results I do not expect that it will be significantly better than write > > performance. I may do some when I get more time to investigate and follow > > up if the results are unexpected. > > Try it. I would expect read performance to be much better. If not, don't > bother trying the above patch. msdosfs uses read-ahead for read(), and > this seems to work well so I haven't even tried changing it to use read > clustering (the above only changes it to use write clustering). This may > depend on the drive doing read caching and not handling small block sizes > too badly. I mostly use ATA drives that have these properties. Writing > tinygrams tends to have a relatively higher cost because write caching is > not enabled so clustering can only be done by the OS. Ok, I still have all the test equipment so I might as well do this today. I have ATA write caching enabled on my systems. > > Hopefully this will generate some interest in the problem, it is beyond > > my time and expertise but it would be very nice to be able to access > > MS-DOS formatted filesystems at a reasonable speed! > > Some other changes are needed for general use at a reasonable speed: > - use VMIO for metadata. > - don't use pessimal block allocation. The current allocator gives > large inter-file fragmentation by attempting to minimise intra-file > fragmentation, and when the file system becomes just 1/N full the > attempt backfires and gives intra-file fragmentation too (files with > more than N clusters are very likely to be fragmented). Is there anyone out there who is sufficently talented, with a strong desire to tackle this problem? I would be happy to make the first payment, or hardware donation into a development fund to see it get fixed. My resources are limited though, so if there are others who would like this feature perhaps we could combine to get a volunteer some really nice kit? > Bruce Thanks very much, -- Dominic GoodforBusiness.co.uk I.T. Services for SMEs in the UK. From owner-freebsd-fs@FreeBSD.ORG Sat May 28 14:39:16 2005 Return-Path: X-Original-To: freebsd-fs@FreeBSD.org Delivered-To: freebsd-fs@FreeBSD.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 69D1716A41C; Sat, 28 May 2005 14:39:16 +0000 (GMT) (envelope-from dom@goodforbusiness.co.uk) Received: from mail.helenmarks.co.uk (mail.helenmarks.co.uk [82.68.196.22]) by mx1.FreeBSD.org (Postfix) with ESMTP id C7D3343D1F; Sat, 28 May 2005 14:39:15 +0000 (GMT) (envelope-from dom@goodforbusiness.co.uk) Received: from localhost (localhost [127.0.0.1]) by mail.helenmarks.co.uk (Postfix) with ESMTP id EE102222404; Sat, 28 May 2005 15:39:14 +0100 (BST) Received: from mail.helenmarks.co.uk ([127.0.0.1]) by localhost (mail.helenmarks.co.uk [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 07500-08; Sat, 28 May 2005 15:39:11 +0100 (BST) Received: from egg.helenmarks.co.uk (egg.helenmarks.co.uk [192.168.15.3]) by mail.helenmarks.co.uk (Postfix) with ESMTP id EA0AA222403; Sat, 28 May 2005 15:39:11 +0100 (BST) From: Dominic Marks Organization: GoodforBusiness.co.uk To: Bruce Evans Date: Sat, 28 May 2005 15:40:34 +0100 User-Agent: KMail/1.8 References: <200505271328.58072.dom@goodforbusiness.co.uk> <20050528194126.W3563@epsplex.bde.org> <200505281213.42118.dom@goodforbusiness.co.uk> In-Reply-To: <200505281213.42118.dom@goodforbusiness.co.uk> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200505281540.35116.dom@goodforbusiness.co.uk> X-Virus-Scanned: By ClamAV 0.80 Cc: freebsd-fs@FreeBSD.org, freebsd-gnats-submit@FreeBSD.org, banhalmi@field.hu Subject: Re: i386/68719: [usb] USB 2.0 mobil rack+ fat32 performance 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: Sat, 28 May 2005 14:39:16 -0000 On Saturday 28 May 2005 12:13, Dominic Marks wrote: > On Saturday 28 May 2005 11:36, Bruce Evans wrote: > > > > I use the following to improve transfer rates for msdosfs. The patch is > > for an old version so it might not apply directly. > > > > %%% > > Index: msdosfs_vnops.c > > =================================================================== > > RCS file: /home/ncvs/src/sys/fs/msdosfs/msdosfs_vnops.c,v > > retrieving revision 1.147 > > diff -u -2 -r1.147 msdosfs_vnops.c > > --- msdosfs_vnops.c 4 Feb 2004 21:52:53 -0000 1.147 > > +++ msdosfs_vnops.c 22 Feb 2004 07:27:15 -0000 > > @@ -608,4 +622,5 @@ > > int error = 0; > > u_long count; > > + int seqcount; > > daddr_t bn, lastcn; > > struct buf *bp; > > @@ -693,4 +714,5 @@ > > lastcn = de_clcount(pmp, osize) - 1; > > > > + seqcount = ioflag >> IO_SEQSHIFT; > > do { > > if (de_cluster(pmp, uio->uio_offset) > lastcn) { > > @@ -718,5 +740,5 @@ > > */ > > bp = getblk(thisvp, bn, pmp->pm_bpcluster, 0, 0, 0); > > - clrbuf(bp); > > + vfs_bio_clrbuf(bp); > > /* > > * Do the bmap now, since pcbmap needs buffers > > @@ -767,11 +789,19 @@ > > * without delay. Otherwise do a delayed write because we > > * may want to write somemore into the block later. > > + * XXX comment not updated with code. > > */ > > + if ((vp->v_mount->mnt_flag & MNT_NOCLUSTERW) == 0) > > + bp->b_flags |= B_CLUSTEROK; > > if (ioflag & IO_SYNC) > > - (void) bwrite(bp); > > - else if (n + croffset == pmp->pm_bpcluster) > > + (void)bwrite(bp); > > + else if (vm_page_count_severe() || buf_dirty_count_severe()) > > bawrite(bp); > > - else > > - bdwrite(bp); > > + else if (n + croffset == pmp->pm_bpcluster) { > > + if ((vp->v_mount->mnt_flag & MNT_NOCLUSTERW) == 0) > > + cluster_write(bp, dep->de_FileSize, seqcount); > > + else > > + bawrite(bp); > > + } else > > + bdwrite(bp); > > dep->de_flag |= DE_UPDATE; > > } while (error == 0 && uio->uio_resid > 0); > > %%% > > Thanks! I'll try my three tests again with this patch. Index: msdosfs_vnops.c =================================================================== RCS file: /usr/cvs/src/sys/fs/msdosfs/msdosfs_vnops.c,v retrieving revision 1.149.2.1 diff -u -r1.149.2.1 msdosfs_vnops.c --- msdosfs_vnops.c 31 Jan 2005 23:25:56 -0000 1.149.2.1 +++ msdosfs_vnops.c 28 May 2005 14:26:59 -0000 @@ -607,6 +607,7 @@ struct uio *a_uio; int a_ioflag; struct ucred *a_cred; + int seqcount; } */ *ap; { int n; @@ -615,6 +616,7 @@ u_long osize; int error = 0; u_long count; + int seqcount; daddr_t bn, lastcn; struct buf *bp; int ioflag = ap->a_ioflag; @@ -692,7 +694,7 @@ */ if (uio->uio_offset + resid > osize) { count = de_clcount(pmp, uio->uio_offset + resid) - - de_clcount(pmp, osize); + de_clcount(pmp, osize); error = extendfile(dep, count, NULL, NULL, 0); if (error && (error != ENOSPC || (ioflag & IO_UNIT))) goto errexit; @@ -700,6 +702,7 @@ } else lastcn = de_clcount(pmp, osize) - 1; + seqcount = ioflag >> IO_SEQSHIFT; do { if (de_cluster(pmp, uio->uio_offset) > lastcn) { error = ENOSPC; @@ -725,7 +728,7 @@ * then no need to read data from disk. */ bp = getblk(thisvp, bn, pmp->pm_bpcluster, 0, 0, 0); - clrbuf(bp); + vfs_bio_clrbuf(bp); /* * Do the bmap now, since pcbmap needs buffers * for the fat table. (see msdosfs_strategy) @@ -775,6 +778,7 @@ * without delay. Otherwise do a delayed write because we * may want to write somemore into the block later. */ + /* if (ioflag & IO_SYNC) (void) bwrite(bp); else if (n + croffset == pmp->pm_bpcluster) @@ -782,6 +786,24 @@ else bdwrite(bp); dep->de_flag |= DE_UPDATE; + */ + /* + * XXX Patch. + */ + if ((vp->v_mount->mnt_flag & MNT_NOCLUSTERW) == 0) + bp->b_flags |= B_CLUSTEROK; + if (ioflag & IO_SYNC) + (void)bwrite(bp); + else if (vm_page_count_severe() || buf_dirty_count_severe()) + bawrite(bp); + else if (n + croffset == pmp->pm_bpcluster) { + if ((vp->v_mount->mnt_flag & MNT_NOCLUSTERW) == 0) + cluster_write(bp, dep->de_FileSize, seqcount); + else + bawrite(bp); + } else + bdwrite(bp); + dep->de_flag |= DE_UPDATE; } while (error == 0 && uio->uio_resid > 0); /* Your patch works for me on 5.4-STABLE. It improves write performance dramatically. I did another test, reading and writing 1GB chunks of data. # dd if= of= bs=512k count=2k ufs2/read: 28.25MB/s ufs2/write: 23.47MB/s msdosfs/read: 5.08MB/s msdosfs/write: 23.13MB/s Raising vfs.read_max to 64 (from 8) seems to have improved the read performance a little too but I have not measured how much yet. Since the patch is to the _write function is it safe to assume the same method could be used to fix read performance if applied properly in the correct function? Cheers, -- Dominic GoodforBusiness.co.uk I.T. Services for SMEs in the UK.