From owner-freebsd-fs@FreeBSD.ORG Sun May 29 15:11:33 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 7D94416A41C; Sun, 29 May 2005 15:11:33 +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 DA6F643D48; Sun, 29 May 2005 15:11:31 +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 D5131222402; Sun, 29 May 2005 16:11:26 +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 84830-06; Sun, 29 May 2005 16:11:23 +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 A8E3B222403; Sun, 29 May 2005 16:11:23 +0100 (BST) From: Dominic Marks Organization: GoodforBusiness.co.uk To: Bruce Evans Date: Sun, 29 May 2005 16:12:46 +0100 User-Agent: KMail/1.8 References: <200505271328.58072.dom@goodforbusiness.co.uk> <200505281213.42118.dom@goodforbusiness.co.uk> <200505281540.35116.dom@goodforbusiness.co.uk> In-Reply-To: <200505281540.35116.dom@goodforbusiness.co.uk> MIME-Version: 1.0 Content-Type: Multipart/Mixed; boundary="Boundary-00=_uvdmCBeoNTBAj+g" Message-Id: <200505291612.46941.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: Sun, 29 May 2005 15:11:33 -0000 --Boundary-00=_uvdmCBeoNTBAj+g Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Content-Disposition: inline On Saturday 28 May 2005 15:40, Dominic Marks wrote: > 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. > > > > > 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. > 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, I have been experimenting in msdosfs_read and I have managed to come up with something that works, but I'm sure it is flawed. On large file reads it will improve read performance (see below) - but only after a long period of the file copy achieving only 3MB/s (see A1). During this time gstat reports the disc itself is reading at its maximum of around 28MB/s. After a long period of low throughput, the disc drops to 25MB/s but the actual transfer rate increases to 25MB/s (see A2). I've tried to narrow it down to something but I'm mostly in the dark, so I'll just hand over what I found to work to review. I looked at Bruce's changes to msdosfs_write and tried to do the same (implement cluster_read) using the ext2 and ffs _read methods as a how-to. I think I'm reading ahead too far, or too early. I have been unable to interpret the gstat output during the first part of the transfer any further. gstat(8) output at the start (slow, A1), and middle (fast, A2) of a large file copy between msdosfs/usb drive (da0s1) and ufs2/ata-100 (ad1). # A1 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 14 445 445 28376 24.7 0 0 0.0 99.9| da0 0 28 0 0 0.0 28 3578 1.7 4.8| ad1 0 28 0 0 0.0 28 3578 1.7 4.8| ad1s1 14 445 445 28376 24.9 0 0 0.0 100.0| da0s1 After 30-45 seconds (1GB test file): # A2 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 1 403 403 25428 2.1 0 0 0.0 85.0| da0 0 199 0 0 0.0 199 25532 1.7 34.0| ad1 0 199 0 0 0.0 199 25532 1.7 34.1| ad1s1 1 403 403 25428 2.1 0 0 0.0 85.9| da0s1 The patch which combines Bruce's original patch for msdosfs_write, revised for current text positions, and my attempts to do the same for msdosfs_read. %% 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 29 May 2005 14:10:18 -0000 @@ -517,6 +517,8 @@ int blsize; int isadir; int orig_resid; + int nblks = 16; /* XXX should be defined, but not here */ + int crsize; u_int n; u_long diff; u_long on; @@ -565,14 +567,21 @@ error = bread(pmp->pm_devvp, lbn, blsize, NOCRED, &bp); } else { blsize = pmp->pm_bpcluster; - rablock = lbn + 1; - if (seqcount > 1 && - de_cn2off(pmp, rablock) < dep->de_FileSize) { - rasize = pmp->pm_bpcluster; - error = breadn(vp, lbn, blsize, - &rablock, &rasize, 1, NOCRED, &bp); + /* XXX what is the best value for crsize? */ + crsize = blsize * nblks > MAXBSIZE ? MAXBSIZE : blsize * nblks; + if ((vp->v_mount->mnt_flag & MNT_NOCLUSTERR) == 0) { + error = cluster_read(vp, dep->de_FileSize, lbn, + crsize, NOCRED, uio->uio_resid, seqcount, &bp); } else { - error = bread(vp, lbn, blsize, NOCRED, &bp); + rablock = lbn + 1; + if (seqcount > 1 && + de_cn2off(pmp, rablock) < dep->de_FileSize) { + rasize = pmp->pm_bpcluster; + error = breadn(vp, lbn, blsize, + &rablock, &rasize, 1, NOCRED, &bp); + } else { + error = bread(vp, lbn, blsize, NOCRED, &bp); + } } } if (error) { @@ -580,14 +589,16 @@ break; } on = uio->uio_offset & pmp->pm_crbomask; - diff = pmp->pm_bpcluster - on; - n = diff > uio->uio_resid ? uio->uio_resid : diff; + diff = blsize * nblks - on; + n = blsize * nblks > uio->uio_resid ? uio->uio_resid : blsize * nblks; diff = dep->de_FileSize - uio->uio_offset; - if (diff < n) + if (diff < n) { n = diff; - diff = blsize - bp->b_resid; - if (diff < n) + } + diff = blsize * nblks - bp->b_resid; + if (diff < n) { n = diff; + } error = uiomove(bp->b_data + on, (int) n, uio); brelse(bp); } while (error == 0 && uio->uio_resid > 0 && n != 0); @@ -607,6 +618,7 @@ struct uio *a_uio; int a_ioflag; struct ucred *a_cred; + int seqcount; } */ *ap; { int n; @@ -615,6 +627,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 +705,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 +713,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 +739,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 +789,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 +797,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); /* %% With this patch I can get the following transfer rates: msdosfs reading # ls -lh /mnt/random2.file -rwxr-xr-x 1 root wheel 1.0G May 29 11:24 /mnt/random2.file # /usr/bin/time -al cp /mnt/random2.file /vol 59.61 real 0.05 user 6.79 sys 632 maximum resident set size 11 average shared memory size 80 average unshared data size 123 average unshared stack size 88 page reclaims 0 page faults 0 swaps 23757 block input operations ** 8192 block output operations 0 messages sent 0 messages received 0 signals received 16660 voluntary context switches 10387 involuntary context switches Average Rate: 15.31MB/s. (Would be higher if not for the slow start) ** This figure is 3x that of the UFS2 operations. This must be a indicator of what I'm doing wrong, but I don't know what. msdosfs writing # /usr/bin/time -al cp /vol/random2.file /mnt 47.33 real 0.03 user 7.13 sys 632 maximum resident set size 12 average shared memory size 85 average unshared data size 130 average unshared stack size 88 page reclaims 0 page faults 0 swaps 8735 block input operations 16385 block output operations 0 messages sent 0 messages received 0 signals received 8856 voluntary context switches 29631 involuntary context switches Average Rate: 18.79MB/s. To compare with UFS2 + softupdates on the same system / disc. ufs2 reading # /usr/bin/time -al cp /mnt/random2.file /vol 42.39 real 0.02 user 6.61 sys 632 maximum resident set size 12 average shared memory size 87 average unshared data size 133 average unshared stack size 88 page reclaims 0 page faults 0 swaps 8249 block input operations 8193 block output operations 0 messages sent 0 messages received 0 signals received 8246 voluntary context switches 24617 involuntary context switches Average Rate: 20.89MB/s. ufs2 writing # /usr/bin/time -al cp /vol/random2.file /mnt/ 47.12 real 0.03 user 6.74 sys 632 maximum resident set size 12 average shared memory size 85 average unshared data size 130 average unshared stack size 88 page reclaims 0 page faults 0 swaps 8260 block input operations 8192 block output operations 0 messages sent 0 messages received 0 signals received 8303 voluntary context switches 24700 involuntary context switches Average Rate: 19MB/s. I'd hope that someone could point me in the right direction so I can clean the patch up, or finish this off themselves and commit it (or something else which will increase the read/write speed). Thanks very much, -- Dominic GoodforBusiness.co.uk I.T. Services for SMEs in the UK. --Boundary-00=_uvdmCBeoNTBAj+g Content-Type: text/x-diff; charset="iso-8859-1"; name="msdos-perf-releng5.patch" Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename="msdos-perf-releng5.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 29 May 2005 14:10:18 -0000 @@ -517,6 +517,8 @@ int blsize; int isadir; int orig_resid; + int nblks = 16; /* XXX should be defined, but not here */ + int crsize; u_int n; u_long diff; u_long on; @@ -565,14 +567,21 @@ error = bread(pmp->pm_devvp, lbn, blsize, NOCRED, &bp); } else { blsize = pmp->pm_bpcluster; - rablock = lbn + 1; - if (seqcount > 1 && - de_cn2off(pmp, rablock) < dep->de_FileSize) { - rasize = pmp->pm_bpcluster; - error = breadn(vp, lbn, blsize, - &rablock, &rasize, 1, NOCRED, &bp); + /* XXX what is the best value for crsize? */ + crsize = blsize * nblks > MAXBSIZE ? MAXBSIZE : blsize * nblks; + if ((vp->v_mount->mnt_flag & MNT_NOCLUSTERR) == 0) { + error = cluster_read(vp, dep->de_FileSize, lbn, + crsize, NOCRED, uio->uio_resid, seqcount, &bp); } else { - error = bread(vp, lbn, blsize, NOCRED, &bp); + rablock = lbn + 1; + if (seqcount > 1 && + de_cn2off(pmp, rablock) < dep->de_FileSize) { + rasize = pmp->pm_bpcluster; + error = breadn(vp, lbn, blsize, + &rablock, &rasize, 1, NOCRED, &bp); + } else { + error = bread(vp, lbn, blsize, NOCRED, &bp); + } } } if (error) { @@ -580,14 +589,16 @@ break; } on = uio->uio_offset & pmp->pm_crbomask; - diff = pmp->pm_bpcluster - on; - n = diff > uio->uio_resid ? uio->uio_resid : diff; + diff = blsize * nblks - on; + n = blsize * nblks > uio->uio_resid ? uio->uio_resid : blsize * nblks; diff = dep->de_FileSize - uio->uio_offset; - if (diff < n) + if (diff < n) { n = diff; - diff = blsize - bp->b_resid; - if (diff < n) + } + diff = blsize * nblks - bp->b_resid; + if (diff < n) { n = diff; + } error = uiomove(bp->b_data + on, (int) n, uio); brelse(bp); } while (error == 0 && uio->uio_resid > 0 && n != 0); @@ -607,6 +618,7 @@ struct uio *a_uio; int a_ioflag; struct ucred *a_cred; + int seqcount; } */ *ap; { int n; @@ -615,6 +627,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 +705,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 +713,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 +739,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 +789,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 +797,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); /* --Boundary-00=_uvdmCBeoNTBAj+g-- From owner-freebsd-fs@FreeBSD.ORG Mon May 30 07:19: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 0C25916A41C; Mon, 30 May 2005 07:19:42 +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 3DCE643D1D; Mon, 30 May 2005 07:19:41 +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 j4U7JTkG030965; Mon, 30 May 2005 17:19:29 +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 j4U7JKqB001379; Mon, 30 May 2005 17:19:22 +1000 Date: Mon, 30 May 2005 17:19:22 +1000 (EST) From: Bruce Evans X-X-Sender: bde@epsplex.bde.org To: Dominic Marks In-Reply-To: <200505291612.46941.dom@goodforbusiness.co.uk> Message-ID: <20050530155609.Q1473@epsplex.bde.org> References: <200505271328.58072.dom@goodforbusiness.co.uk> <200505281213.42118.dom@goodforbusiness.co.uk> <200505281540.35116.dom@goodforbusiness.co.uk> <200505291612.46941.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: Mon, 30 May 2005 07:19:42 -0000 On Sun, 29 May 2005, Dominic Marks wrote: > I have been experimenting in msdosfs_read and I have managed to come up with > something that works, but I'm sure it is flawed. On large file reads it will > improve read performance (see below) - but only after a long period of the > file copy achieving only 3MB/s (see A1). During this time gstat reports the > disc itself is reading at its maximum of around 28MB/s. After a long period > of low throughput, the disc drops to 25MB/s but the actual transfer rate > increases to 25MB/s (see A2). A1 is strange. It might be reading too much ahead, but I wouldn't expect the read-ahead to be discarded soon so this should make little difference for reading whole files. > I've tried to narrow it down to something but I'm mostly in the dark, so I'll > just hand over what I found to work to review. I looked at Bruce's changes to > msdosfs_write and tried to do the same (implement cluster_read) using the > ext2 and ffs _read methods as a how-to. I think I'm reading ahead too far, or > too early. I have been unable to interpret the gstat output during the first > part of the transfer any further. The ext2 and ffs methods are a good place to start. Also look at cd9660 -- it is a little simpler. > The patch which combines Bruce's original patch for msdosfs_write, revised for > current text positions, and my attempts to do the same for msdosfs_read. > > %% > 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 29 May 2005 14:10:18 -0000 > @@ -565,14 +567,21 @@ > error = bread(pmp->pm_devvp, lbn, blsize, NOCRED, &bp); > } else { > blsize = pmp->pm_bpcluster; > - rablock = lbn + 1; > - if (seqcount > 1 && > - de_cn2off(pmp, rablock) < dep->de_FileSize) { > - rasize = pmp->pm_bpcluster; > - error = breadn(vp, lbn, blsize, > - &rablock, &rasize, 1, NOCRED, &bp); > + /* XXX what is the best value for crsize? */ > + crsize = blsize * nblks > MAXBSIZE ? MAXBSIZE : blsize * nblks; > + if ((vp->v_mount->mnt_flag & MNT_NOCLUSTERR) == 0) { > + error = cluster_read(vp, dep->de_FileSize, lbn, > + crsize, NOCRED, uio->uio_resid, seqcount, &bp); crsize should be just the block size (cluster size in msdosfs and blsize variable here) according to this code in all other file systems. seqcount gives the amount of readahead and there are algorithms elsewhere to guess its best value. I think cluster_read() reads only physically contiguous blocks, so the amount of read-ahead for it is not critical for the clustered case anyway. There will either be a large range of contigous blocks, in which case reading ahead a lot isn't bad, or read-ahead will be limited by discontiguities. Giving a too-large value for crsize may be harmful by confusing cluster_read() about discontiguities, or just by asking it to read the large size when the blocks actually in the file aren't contiguous. I think the above handles most cases, so look for problems there first. > } else { The above seems to be missing a bread() for the EOF case (before the else). I don't know what cluster_read() does at EOF. See cd9660_read() for clear code. (Here there is unfortunately an extra level of indentation from a special case for directories.) > - error = bread(vp, lbn, blsize, NOCRED, &bp); > + rablock = lbn + 1; > + if (seqcount > 1 && > + de_cn2off(pmp, rablock) < dep->de_FileSize) { > + rasize = pmp->pm_bpcluster; > + error = breadn(vp, lbn, blsize, > + &rablock, &rasize, 1, NOCRED, &bp); > + } else { > + error = bread(vp, lbn, blsize, NOCRED, &bp); > + } This part seems to be OK. (It is just the old code indented.) > } > } > if (error) { > ... > %% > > With this patch I can get the following transfer rates: > > msdosfs reading > > # ls -lh /mnt/random2.file > -rwxr-xr-x 1 root wheel 1.0G May 29 11:24 /mnt/random2.file > > # /usr/bin/time -al cp /mnt/random2.file /vol > 59.61 real 0.05 user 6.79 sys > 632 maximum resident set size > 11 average shared memory size > 80 average unshared data size > 123 average unshared stack size > 88 page reclaims > 0 page faults > 0 swaps > 23757 block input operations ** > 8192 block output operations > 0 messages sent > 0 messages received > 0 signals received > 16660 voluntary context switches > 10387 involuntary context switches > > Average Rate: 15.31MB/s. (Would be higher if not for the slow start) > > ** This figure is 3x that of the UFS2 operations. This must be a indicator of > what I'm doing wrong, but I don't know what. This might also be a sign of fragmentation due to bad allocation policies at write time or write() not being able to do good allocation due to previous fragmentation. The average rate isn't too bad, despite the extra blocks. > msdosfs writing > > # /usr/bin/time -al cp /vol/random2.file /mnt > 47.33 real 0.03 user 7.13 sys > 632 maximum resident set size > 12 average shared memory size > 85 average unshared data size > 130 average unshared stack size > 88 page reclaims > 0 page faults > 0 swaps > 8735 block input operations > 16385 block output operations > 0 messages sent > 0 messages received > 0 signals received > 8856 voluntary context switches > 29631 involuntary context switches > > Average Rate: 18.79MB/s. There are 2x as many blocks as for ffs2 for writing instead of 3x for reading. What are the input blocks for here? Better put the non-msdosfs part of the source or target in memory so that it doesn't get counted. Or try mount -v (it gives sync and async read/write counts for individual file systems). 2x is actually believable while ffs2's counts aren't. It corresponds to a block size of 64K, which is what I would expect for the unfragmented case. > To compare with UFS2 + softupdates on the same system / disc. > > ufs2 reading > > # /usr/bin/time -al cp /mnt/random2.file /vol > 42.39 real 0.02 user 6.61 sys > 632 maximum resident set size > 12 average shared memory size > 87 average unshared data size > 133 average unshared stack size > 88 page reclaims > 0 page faults > 0 swaps > 8249 block input operations > 8193 block output operations > 0 messages sent > 0 messages received > 0 signals received > 8246 voluntary context switches > 24617 involuntary context switches > > Average Rate: 20.89MB/s. Isn't it 24.16MB/s? 8192 i/o operations seems to be too small. It corresponds to a block size of 128K. Most drivers don't actually support doing i/o of that size (most have a limit of 64K), so if they get asked to then it is a bug. This bug is common or ubiquitous. The block size to use for clusters is in mnt_iosize_max, and this is set in various wrong ways, often or always to MAXPHYS = 128K. This usually makes little difference except to give misleading statistics. Clustering tends to produce blocks of size 128K and the block i/o counts report blocks of that sizes, but smaller blocks are sent to the hardware. I'm not sure if libdevstat() sees the smaller blocks. I think it doesn't. > [... ufs2 writing similar to reading] Bruce From owner-freebsd-fs@FreeBSD.ORG Mon May 30 10:11:59 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 BF14E16A41C; Mon, 30 May 2005 10:11:59 +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 11F6943D54; Mon, 30 May 2005 10:11:58 +0000 (GMT) (envelope-from bde@zeta.org.au) Received: from mailproxy2.pacific.net.au (mailproxy2.pacific.net.au [61.8.0.87]) by mailout2.pacific.net.au (8.12.3/8.12.3/Debian-7.1) with ESMTP id j4UABmkG005619; Mon, 30 May 2005 20:11:48 +1000 Received: from epsplex.bde.org (katana.zip.com.au [61.8.7.246]) by mailproxy2.pacific.net.au (8.12.3/8.12.3/Debian-7.1) with ESMTP id j4UABiMC012521; Mon, 30 May 2005 20:11:44 +1000 Date: Mon, 30 May 2005 20:11:45 +1000 (EST) From: Bruce Evans X-X-Sender: bde@epsplex.bde.org To: Dominic Marks In-Reply-To: <20050530155609.Q1473@epsplex.bde.org> Message-ID: <20050530193711.I843@epsplex.bde.org> References: <200505271328.58072.dom@goodforbusiness.co.uk> <200505281213.42118.dom@goodforbusiness.co.uk> <200505281540.35116.dom@goodforbusiness.co.uk> <200505291612.46941.dom@goodforbusiness.co.uk> <20050530155609.Q1473@epsplex.bde.org> 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: Mon, 30 May 2005 10:11:59 -0000 On Mon, 30 May 2005, Bruce Evans wrote: > On Sun, 29 May 2005, Dominic Marks wrote: >> I have been experimenting in msdosfs_read and I have managed to come up >> with >> something that works, but I'm sure it is flawed. On large file reads it >> will >> ... >> %% >> 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 29 May 2005 14:10:18 -0000 >> @@ -565,14 +567,21 @@ >> error = bread(pmp->pm_devvp, lbn, blsize, NOCRED, >> &bp); >> } else { >> blsize = pmp->pm_bpcluster; >> - rablock = lbn + 1; >> - if (seqcount > 1 && >> - de_cn2off(pmp, rablock) < dep->de_FileSize) { >> - rasize = pmp->pm_bpcluster; >> - error = breadn(vp, lbn, blsize, >> - &rablock, &rasize, 1, NOCRED, &bp); >> + /* XXX what is the best value for crsize? */ >> + crsize = blsize * nblks > MAXBSIZE ? MAXBSIZE : >> blsize * nblks; >> + if ((vp->v_mount->mnt_flag & MNT_NOCLUSTERR) == 0) { >> + error = cluster_read(vp, dep->de_FileSize, >> lbn, >> + crsize, NOCRED, uio->uio_resid, >> seqcount, &bp); > > crsize should be just the block size (cluster size in msdosfs and > blsize variable here) according to this code in all other file systems. > ... The main problem is that VOP_BMAP() is not fully implemented for msdosfs. msdosfs_bmap() only has a stub which pretends that clustering ins never possible: % /* % * vp - address of vnode file the file % * bn - which cluster we are interested in mapping to a filesystem block number. % * vpp - returns the vnode for the block special file holding the filesystem % * containing the file of interest % * bnp - address of where to return the filesystem relative block number % */ This comment rotted in 1994 when 4.4BSD packed the args into a struct and added the a_runp and a_runb args to support clustering. % static int % msdosfs_bmap(ap) % struct vop_bmap_args /* { % struct vnode *a_vp; % daddr_t a_bn; % struct vnode **a_vpp; % daddr_t *a_bnp; % int *a_runp; % int *a_runb; % } */ *ap; % { % struct denode *dep = VTODE(ap->a_vp); % daddr_t blkno; % int error; % % if (ap->a_vpp != NULL) % *ap->a_vpp = dep->de_devvp; % if (ap->a_bnp == NULL) % return (0); % if (ap->a_runp) { % /* % * Sequential clusters should be counted here. ^^^^^^^^^ % */ % *ap->a_runp = 0; % } % if (ap->a_runb) { % *ap->a_runb = 0; % } % error = pcbmap(dep, ap->a_bn, &blkno, 0, 0); % *ap->a_bnp = blkno; % return (error); % } Here is a cleaned up version of the patch to add (not actually working) clustering to msdosfs_read(). %%% 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 30 May 2005 08:57:02 -0000 @@ -541,5 +555,7 @@ if (uio->uio_offset >= dep->de_FileSize) break; + blsize = pmp->pm_bpcluster; lbn = de_cluster(pmp, uio->uio_offset); + rablock = lbn + 1; /* * If we are operating on a directory file then be sure to @@ -556,15 +573,15 @@ break; error = bread(pmp->pm_devvp, lbn, blsize, NOCRED, &bp); + } else if (de_cn2off(pmp, rablock) >= dep->de_FileSize) { + error = bread(vp, lbn, blsize, NOCRED, &bp); + } else if ((vp->v_mount->mnt_flag & MNT_NOCLUSTERR) == 0) { + error = cluster_read(vp, dep->de_FileSize, lbn, blsize, + NOCRED, uio->uio_resid, seqcount, &bp); + } else if (seqcount > 1) { + rasize = blsize; + error = breadn(vp, lbn, + blsize, &rablock, &rasize, 1, NOCRED, &bp); } else { - blsize = pmp->pm_bpcluster; - rablock = lbn + 1; - if (seqcount > 1 && - de_cn2off(pmp, rablock) < dep->de_FileSize) { - rasize = pmp->pm_bpcluster; - error = breadn(vp, lbn, blsize, - &rablock, &rasize, 1, NOCRED, &bp); - } else { - error = bread(vp, lbn, blsize, NOCRED, &bp); - } + error = bread(vp, lbn, blsize, NOCRED, &bp); } if (error) { %%% I rearranged the code to be almost lexically identical with that in ffs_read(). I only tested this on a relatively fast ATA drive. It made little difference. Most writes were clustered to give a block size of 64K and write speed of over 40+MB/s until the disk is nearly full, but reads weren't clustered with or without the patch so the block size remained at the fs block size (4K); the drive handles this block size mediocrely and gave a read speed of 20+MB/sec. (The drive is a WDC 1200JB-00CRA1. This drive has the interesting behaviour of giving almost the same mediocre read speed for all block sizes between 2.5K and 19.5K. A block size 20K gives maximal speed which is about twice as fast as the speed for a block size of 19.5K.) Both reading and writing a 1GB file to/from msdosfs caused noticable buffer resource problems. Accesses to other file systems on the same disk sometimes blocked for many seconds. I have debugging code in getblk(). It reported that a process waited 17 seconds in or near getblk(). The process only stopped waiting because I suspended the process accessing msdosfs. This may be a local bug. Bruce From owner-freebsd-fs@FreeBSD.ORG Mon May 30 15:07:58 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 AFA8816A41C; Mon, 30 May 2005 15:07:58 +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 D193243D4C; Mon, 30 May 2005 15:07:57 +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 87BE0222403; Mon, 30 May 2005 16:07:52 +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 56399-07; Mon, 30 May 2005 16:07:47 +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 7EC90222402; Mon, 30 May 2005 16:07:47 +0100 (BST) From: Dominic Marks Organization: GoodforBusiness.co.uk To: Bruce Evans Date: Mon, 30 May 2005 16:09:11 +0100 User-Agent: KMail/1.8 References: <200505271328.58072.dom@goodforbusiness.co.uk> <20050530155609.Q1473@epsplex.bde.org> <20050530193711.I843@epsplex.bde.org> In-Reply-To: <20050530193711.I843@epsplex.bde.org> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200505301609.11857.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: Mon, 30 May 2005 15:07:58 -0000 On Monday 30 May 2005 11:11, Bruce Evans wrote: > On Mon, 30 May 2005, Bruce Evans wrote: > > On Sun, 29 May 2005, Dominic Marks wrote: > >> I have been experimenting in msdosfs_read and I have managed to come up > >> with > >> something that works, but I'm sure it is flawed. On large file reads it > >> will > >> ... > >> %% > >> 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 29 May 2005 14:10:18 -0000 > >> @@ -565,14 +567,21 @@ > >> error = bread(pmp->pm_devvp, lbn, blsize, NOCRED, > >> &bp); > >> } else { > >> blsize = pmp->pm_bpcluster; > >> - rablock = lbn + 1; > >> - if (seqcount > 1 && > >> - de_cn2off(pmp, rablock) < dep->de_FileSize) { > >> - rasize = pmp->pm_bpcluster; > >> - error = breadn(vp, lbn, blsize, > >> - &rablock, &rasize, 1, NOCRED, &bp); > >> + /* XXX what is the best value for crsize? */ > >> + crsize = blsize * nblks > MAXBSIZE ? MAXBSIZE : > >> blsize * nblks; > >> + if ((vp->v_mount->mnt_flag & MNT_NOCLUSTERR) == 0) { > >> + error = cluster_read(vp, dep->de_FileSize, > >> lbn, > >> + crsize, NOCRED, uio->uio_resid, > >> seqcount, &bp); > > > > crsize should be just the block size (cluster size in msdosfs and > > blsize variable here) according to this code in all other file systems. > > ... > > The main problem is that VOP_BMAP() is not fully implemented for msdosfs. > msdosfs_bmap() only has a stub which pretends that clustering ins never > possible: > > % /* > % * vp - address of vnode file the file > % * bn - which cluster we are interested in mapping to a filesystem block > number. % * vpp - returns the vnode for the block special file holding the > filesystem % * containing the file of interest > % * bnp - address of where to return the filesystem relative block number > % */ > > This comment rotted in 1994 when 4.4BSD packed the args into a struct > and added the a_runp and a_runb args to support clustering. > > % static int > % msdosfs_bmap(ap) > % struct vop_bmap_args /* { > % struct vnode *a_vp; > % daddr_t a_bn; > % struct vnode **a_vpp; > % daddr_t *a_bnp; > % int *a_runp; > % int *a_runb; > % } */ *ap; > % { > % struct denode *dep = VTODE(ap->a_vp); > % daddr_t blkno; > % int error; > % > % if (ap->a_vpp != NULL) > % *ap->a_vpp = dep->de_devvp; > % if (ap->a_bnp == NULL) > % return (0); > % if (ap->a_runp) { > % /* > % * Sequential clusters should be counted here. > ^^^^^^^^^ > % */ > % *ap->a_runp = 0; > % } > % if (ap->a_runb) { > % *ap->a_runb = 0; > % } > % error = pcbmap(dep, ap->a_bn, &blkno, 0, 0); > % *ap->a_bnp = blkno; > % return (error); > % } If I understand what is supposed to be done here (I looked at cd9660 but I don't know if the rules are different from msdos), a_runp should be set to the extent of contiguous blocks from the current position within the same region? I put some debugging into msdosfs_bmap and here it is copied: (fsz is dep->de_FileSize) msdosfs_bmap: fsz 81047 blkno 6374316 lblkno 5 msdosfs_bmap: fsz 81047 blkno 6374324 lblkno 6 msdosfs_bmap: fsz 81047 blkno 6374332 lblkno 7 msdosfs_bmap: fsz 81047 blkno 6374340 lblkno 8 msdosfs_bmap: fsz 81047 blkno 6374348 lblkno 9 msdosfs_bmap: fsz 81047 blkno 6374356 lblkno 10 msdosfs_bmap: fsz 81047 blkno 6374364 lblkno 11 msdosfs_bmap: fsz 81047 blkno 6374372 lblkno 12 # A1 msdosfs_bmap: fsz 81047 blkno 13146156 lblkno 13 # A2 msdosfs_bmap: fsz 81047 blkno 13146156 lblkno 14 msdosfs_bmap: fsz 81047 blkno 13146156 lblkno 15 msdosfs_bmap: fsz 81047 blkno 13146156 lblkno 16 msdosfs_bmap: fsz 81047 blkno 13146156 lblkno 17 msdosfs_bmap: fsz 81047 blkno 13146156 lblkno 18 msdosfs_bmap: fsz 81047 blkno 13146156 lblkno 19 I should compute the position of the boundary illustrated in A1 I should set that to the read ahead value, until setting a new value at A2, perhaps this should only be done for particularly large files? I will look at the other _bmap routines to see what they do. > Here is a cleaned up version of the patch to add (not actually working) > clustering to msdosfs_read(). > > %%% > 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 30 May 2005 08:57:02 -0000 > @@ -541,5 +555,7 @@ > if (uio->uio_offset >= dep->de_FileSize) > break; > + blsize = pmp->pm_bpcluster; > lbn = de_cluster(pmp, uio->uio_offset); > + rablock = lbn + 1; > /* > * If we are operating on a directory file then be sure to > @@ -556,15 +573,15 @@ > break; > error = bread(pmp->pm_devvp, lbn, blsize, NOCRED, &bp); > + } else if (de_cn2off(pmp, rablock) >= dep->de_FileSize) { > + error = bread(vp, lbn, blsize, NOCRED, &bp); > + } else if ((vp->v_mount->mnt_flag & MNT_NOCLUSTERR) == 0) { > + error = cluster_read(vp, dep->de_FileSize, lbn, blsize, > + NOCRED, uio->uio_resid, seqcount, &bp); > + } else if (seqcount > 1) { > + rasize = blsize; > + error = breadn(vp, lbn, > + blsize, &rablock, &rasize, 1, NOCRED, &bp); > } else { > - blsize = pmp->pm_bpcluster; > - rablock = lbn + 1; > - if (seqcount > 1 && > - de_cn2off(pmp, rablock) < dep->de_FileSize) { > - rasize = pmp->pm_bpcluster; > - error = breadn(vp, lbn, blsize, > - &rablock, &rasize, 1, NOCRED, &bp); > - } else { > - error = bread(vp, lbn, blsize, NOCRED, &bp); > - } > + error = bread(vp, lbn, blsize, NOCRED, &bp); > } > if (error) { > %%% > > I rearranged the code to be almost lexically identical with that in > ffs_read(). Thanks, I will use this as a basis for any other things I try. > I only tested this on a relatively fast ATA drive. It made little > difference. Most writes were clustered to give a block size of 64K > and write speed of over 40+MB/s until the disk is nearly full, but > reads weren't clustered with or without the patch so the block size > remained at the fs block size (4K); the drive handles this block size > mediocrely and gave a read speed of 20+MB/sec. (The drive is a WDC > 1200JB-00CRA1. This drive has the interesting behaviour of giving > almost the same mediocre read speed for all block sizes between 2.5K > and 19.5K. A block size 20K gives maximal speed which is about twice > as fast as the speed for a block size of 19.5K.) I am still confused as to how reading blsize * 16 actually improved the transfer rate after a long period of making it worse. Perhaps it is related to the buffer resource problem you describe below. > Both reading and writing a 1GB file to/from msdosfs caused noticable > buffer resource problems. Accesses to other file systems on the same > disk sometimes blocked for many seconds. I have debugging code in > getblk(). It reported that a process waited 17 seconds in or near > getblk(). The process only stopped waiting because I suspended the > process accessing msdosfs. This may be a local bug. I'll look for buffer resource statistics in the system tools and measure those. There are no obvious signs, to me, that the systems are in any specific difficulties while running the transfers. > Bruce Thanks a lot for the answers and code, -- Dominic GoodforBusiness.co.uk I.T. Services for SMEs in the UK. From owner-freebsd-fs@FreeBSD.ORG Tue May 31 03:05:37 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 A655616A41C; Tue, 31 May 2005 03:05:37 +0000 (GMT) (envelope-from bde@zeta.org.au) Received: from mailout1.pacific.net.au (mailout1.pacific.net.au [61.8.0.84]) by mx1.FreeBSD.org (Postfix) with ESMTP id 2497143D1F; Tue, 31 May 2005 03:05:36 +0000 (GMT) (envelope-from bde@zeta.org.au) Received: from mailproxy2.pacific.net.au (mailproxy2.pacific.net.au [61.8.0.87]) by mailout1.pacific.net.au (8.12.3/8.12.3/Debian-7.1) with ESMTP id j4V35UrI014020; Tue, 31 May 2005 13:05:30 +1000 Received: from katana.zip.com.au (katana.zip.com.au [61.8.7.246]) by mailproxy2.pacific.net.au (8.12.3/8.12.3/Debian-7.1) with ESMTP id j4V35PMC025588; Tue, 31 May 2005 13:05:27 +1000 Date: Tue, 31 May 2005 13:05:26 +1000 (EST) From: Bruce Evans X-X-Sender: bde@delplex.bde.org To: Dominic Marks In-Reply-To: <200505301609.11857.dom@goodforbusiness.co.uk> Message-ID: <20050531115604.S91592@delplex.bde.org> References: <200505271328.58072.dom@goodforbusiness.co.uk> <20050530155609.Q1473@epsplex.bde.org> <20050530193711.I843@epsplex.bde.org> <200505301609.11857.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: Tue, 31 May 2005 03:05:37 -0000 On Mon, 30 May 2005, Dominic Marks wrote: > On Monday 30 May 2005 11:11, Bruce Evans wrote: >> The main problem is that VOP_BMAP() is not fully implemented for msdosfs. >> msdosfs_bmap() only has a stub which pretends that clustering ins never >> possible: > > If I understand what is supposed to be done here (I looked at cd9660 but > I don't know if the rules are different from msdos), a_runp should be set > to the extent of contiguous blocks from the current position within the > same region? I put some debugging into msdosfs_bmap and here it is copied: cd9660 is deceptively simple here because (I think) it allocates files in perfectly contiguous extents. msdosfs, ffs^ufs and ext2fs have to do considerable work to map even a single block. The details are in pcbmap() for msdosfs. (The name of this function dates from when msdosfs was named pcfs.) I think msdosfs_bmap() just needs to call this function for each block following the start block until a discontiguity is hit or a limit (*) is reached. ufs and ext2fs have an optimized and obfucsated version of this, with multiple blocks looked up at once and the single-block lookup implemented as a multiple-block lookup with a count of 1. I doubt that this optimization is significant even for ufs, at least now that CPUs are 10 to 100 times as fast relative to I/O as when it was implemented. However it is easier to optimize for msdosfs since there are no indirect blocks. All of cd9660, ufs and ext2fs have a whole file *_bmap.c for bmapping. ext2_bmaparray() is simplest, but bmapping in ext2fs and ufs is so similar that misspelling ext2_getlbns() as ufs_getlbns() in 1 caller is harmless. (*) The correct limit is mnt_iosize_max bytes. cd9660 uses the wrong limit of MAXBSIZE. > (fsz is dep->de_FileSize) > > msdosfs_bmap: fsz 81047 blkno 6374316 lblkno 5 > ... > msdosfs_bmap: fsz 81047 blkno 6374364 lblkno 11 > msdosfs_bmap: fsz 81047 blkno 6374372 lblkno 12 # A1 > msdosfs_bmap: fsz 81047 blkno 13146156 lblkno 13 # A2 > msdosfs_bmap: fsz 81047 blkno 13146156 lblkno 14 > ... > > I should compute the position of the boundary illustrated in A1 I should set > that to the read ahead value, until setting a new value at A2, perhaps this > should only be done for particularly large files? I will look at the other > _bmap routines to see what they do. Better to do it for all files. For small files there are just fewer blocks to check for contiguity. > I am still confused as to how reading blsize * 16 actually improved > the transfer rate after a long period of making it worse. Perhaps it > is related to the buffer resource problem you describe below. Could be. The buffer cache layer doesn't handle either overlapping buffers or variant buffer sizes very well. Buffer sizes of (blsize * 16) mixed with buffer sizes of blsize for msdosfs and 16K for ffs may excercise both of these. Bruce From owner-freebsd-fs@FreeBSD.ORG Tue May 31 07:38:36 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 8D47616A41C for ; Tue, 31 May 2005 07:38:36 +0000 (GMT) (envelope-from crankier@ganzartwork.com) Received: from ptrt.dravanet.hu (ptrt.dravanet.hu [81.183.253.7]) by mx1.FreeBSD.org (Postfix) with SMTP id 094EA43D1F for ; Tue, 31 May 2005 07:38:35 +0000 (GMT) (envelope-from crankier@ganzartwork.com) Received: from [220.175.57.38] (port=4393 helo=[fornication]) by ptrt.dravanet.hu with esmtp id 8163640104shares17830 for freebsd-fs@freebsd.org; Tue, 31 May 2005 09:40:17 +0200 Mime-Version: 1.0 (Apple Message framework v728) Content-Transfer-Encoding: 7bit Message-Id: <876816622.6933916945@ptrt.dravanet.hu> Content-Type: text/plain; charset=US-ASCII; format=flowed To: freebsd-fs@freebsd.org From: Dolly Date: Tue, 31 May 2005 09:40:16 +0200 X-Mailer: Apple Mail (2.728) Subject: Helping you stay on top 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, 31 May 2005 07:38:36 -0000 The Best Place To Find The Cheapest Medicine. http://jqxoj.417fqnmx1emc8n4.visional72d3.com Television: chewing gum for the eyes. Get this (economic plan) passed. Later on, we can all debate it. I don't feel good. From owner-freebsd-fs@FreeBSD.ORG Thu Jun 2 09:31: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 602BF16A41C for ; Thu, 2 Jun 2005 09:31:35 +0000 (GMT) (envelope-from ut@bhi-hamburg.de) Received: from mail.terralink.de (mail.tlink.de [217.9.16.16]) by mx1.FreeBSD.org (Postfix) with ESMTP id E3AB143D1F for ; Thu, 2 Jun 2005 09:31:34 +0000 (GMT) (envelope-from ut@bhi-hamburg.de) Received: from schweinkram.pleach-hamburg.de (p548EE00B.dip.t-dialin.net [84.142.224.11]) by mail.terralink.de (Postfix) with ESMTP id BA641B8F6 for ; Thu, 2 Jun 2005 11:31:36 +0200 (CEST) Received: from localhost (localhost [127.0.0.1]) by schweinkram.pleach-hamburg.de (Postfix) with ESMTP id C47BB6A2E43; Thu, 2 Jun 2005 11:29:13 +0200 (CEST) Received: from by localhost (amavisd-new, port ) id cOhRqN2t; Thu, 2 Jun 2005 11:29:12 +0200 (CEST) Received: by schweinkram.pleach-hamburg.de (Postfix, from userid 65534) id 532EC6A22CE; Thu, 2 Jun 2005 11:29:12 +0200 (CEST) Received: from titusn (titusn.pleach-hamburg.de [192.168.1.19]) by schweinkram.pleach-hamburg.de (Postfix) with SMTP id 388506A17FE; Thu, 2 Jun 2005 11:29:10 +0200 (CEST) From: "Titus von Boxberg" To: Date: Thu, 2 Jun 2005 11:32:00 +0200 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0) X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2527 Importance: Normal X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on schweinkram.pleach-hamburg.de X-Spam-Status: No, hits=0.0 required=5.0 tests=BAYES_50 autolearn=no version=2.60 X-Spam-Level: X-Virus-Scanned: by amavisd-new at pleach-hamburg.de Subject: Inconsistent snapshot contents during backup 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, 02 Jun 2005 09:31:35 -0000 Hi there, on two servers we do daily backups onto a tape of a mounted snapshot via tar. The problem is that on both machines almost always one or a few files differ. Here's what we do: #!/bin sh .... mksnap_ffs / /.snap/backupsnap mdconfig -a -t vnode -f /.snap/backupsnap -u 5 mount -o ro /dev/md5 /mnt cd /mnt cp fileinquestion /tmp/x1 # see below tar cf /dev/sa0 .... cp fileinquestion /tmp/x2 # see below tar df /dev/sa0 .... if [ $? -eq 1 ] ; then # see below tar -C /tmp -xf /dev/sa0 fileinquestion mv /tmp/fileinquestion /tmp/x3 fi .... On both machines, the second tar complains that the contents of a file is differing (but not the size). It's always the same file (a cyrus imap database). To see whats happening, we copied the file immediately after the mount of the snapshot into a directory outside the snapshot, also took a copy of the snapshotted file after the backup tar and read back the file from tape after the complaint of the verifying tar (see indented code above). We noticed that almost always none of the copies (x1, x2, x3) were identical. This means that also the files x1 and x2 that are never copied and read back to/from tape differ. We tried to analyze the differences over several days but could not see anything magical. Is there anything wrong with the script or the underlying assumptions ? If not, any ideas what could we do to analyze the problem? The system on the first machine is 5.2.1 RELEASE, the system on the second is 5.3 RELEASE Cheers Titus From owner-freebsd-fs@FreeBSD.ORG Fri Jun 3 02:24:28 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 A17AF16A41C; Fri, 3 Jun 2005 02:24:28 +0000 (GMT) (envelope-from rodrigc@crodrigues.org) Received: from rwcrmhc11.comcast.net (rwcrmhc11.comcast.net [204.127.198.35]) by mx1.FreeBSD.org (Postfix) with ESMTP id 1F8E943D49; Fri, 3 Jun 2005 02:24:27 +0000 (GMT) (envelope-from rodrigc@crodrigues.org) Received: from dibbler.crodrigues.org (c-66-30-114-143.hsd1.ma.comcast.net[66.30.114.143]) by comcast.net (rwcrmhc11) with ESMTP id <20050603022427013004mrpue>; Fri, 3 Jun 2005 02:24:27 +0000 Received: from c-66-30-114-143.hsd1.ma.comcast.net (localhost.127.in-addr.arpa [127.0.0.1]) by dibbler.crodrigues.org (8.13.3/8.13.1) with ESMTP id j532OiCv034112; Thu, 2 Jun 2005 22:24:44 -0400 (EDT) (envelope-from rodrigc@c-66-30-114-143.hsd1.ma.comcast.net) Received: (from rodrigc@localhost) by c-66-30-114-143.hsd1.ma.comcast.net (8.13.3/8.13.1/Submit) id j532Oi3Z034111; Thu, 2 Jun 2005 22:24:44 -0400 (EDT) (envelope-from rodrigc) Date: Thu, 2 Jun 2005 22:24:44 -0400 From: Craig Rodrigues To: freebsd-fs@freebsd.org Message-ID: <20050603022444.GA34086@crodrigues.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.5.9i Cc: dumbbell@freebsd.org, freebsd-arch@freebsd.org Subject: [RFC] Move reiserfs code to src/sys/gnu/fs? 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, 03 Jun 2005 02:24:28 -0000 Hi, Due to the increasing number of filesystems with GNU licenses being imported into the tree (Reiserfs was just imported, and sometime in the future, XFS may be imported), I suggest that a new directory be created: src/sys/gnu/fs I also suggest that the recent Reiserfs code which was imported into the tree be moved from src/sys/gnu/reiserfs to src/sys/gnu/fs/reiserfs Since the code was just imported, this operation should be a simple case of cvs rm'ing the files that exist, and cvs add'ing them to the new directory. At some point, it would be nice to move ext2fs to src/sys/gnu/fs, but that would involve more work (a repo copy). What do people think? Thanks. -- Craig Rodrigues rodrigc@crodrigues.org From owner-freebsd-fs@FreeBSD.ORG Fri Jun 3 02:34:51 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 90D1616A41C; Fri, 3 Jun 2005 02:34:51 +0000 (GMT) (envelope-from scottl@samsco.org) Received: from pooker.samsco.org (pooker.samsco.org [168.103.85.57]) by mx1.FreeBSD.org (Postfix) with ESMTP id 3021843D1F; Fri, 3 Jun 2005 02:34:51 +0000 (GMT) (envelope-from scottl@samsco.org) Received: from [192.168.254.11] (junior.samsco.home [192.168.254.11]) (authenticated bits=0) by pooker.samsco.org (8.13.3/8.13.3) with ESMTP id j532fORQ030787; Thu, 2 Jun 2005 20:41:24 -0600 (MDT) (envelope-from scottl@samsco.org) Message-ID: <429FC188.8080805@samsco.org> Date: Thu, 02 Jun 2005 20:33:44 -0600 From: Scott Long User-Agent: Mozilla/5.0 (X11; U; FreeBSD i386; en-US; rv:1.7.5) Gecko/20050218 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Craig Rodrigues References: <20050603022444.GA34086@crodrigues.org> In-Reply-To: <20050603022444.GA34086@crodrigues.org> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Status: No, score=-2.8 required=3.8 tests=ALL_TRUSTED autolearn=failed version=3.0.2 X-Spam-Checker-Version: SpamAssassin 3.0.2 (2004-11-16) on pooker.samsco.org Cc: freebsd-fs@freebsd.org, dumbbell@freebsd.org, freebsd-arch@freebsd.org Subject: Re: [RFC] Move reiserfs code to src/sys/gnu/fs? 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, 03 Jun 2005 02:34:51 -0000 Craig Rodrigues wrote: > Hi, > > Due to the increasing number of filesystems with GNU licenses > being imported into the tree (Reiserfs was just imported, and > sometime in the future, XFS may be imported), I suggest > that a new directory be created: > > src/sys/gnu/fs > > I also suggest that the recent Reiserfs code which was imported > into the tree be moved from > src/sys/gnu/reiserfs to src/sys/gnu/fs/reiserfs > > Since the code was just imported, this operation should be > a simple case of cvs rm'ing the files that exist, and cvs add'ing > them to the new directory. > > At some point, it would be nice to move ext2fs to > src/sys/gnu/fs, but that would involve more work (a repo copy). > > What do people think? > > Thanks. > I agree! Scott From owner-freebsd-fs@FreeBSD.ORG Fri Jun 3 06:37:52 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 7BBEF16A41C; Fri, 3 Jun 2005 06:37:52 +0000 (GMT) (envelope-from ru@ip.net.ua) Received: from tigra.ip.net.ua (tigra.ip.net.ua [82.193.96.10]) by mx1.FreeBSD.org (Postfix) with ESMTP id CB88543D53; Fri, 3 Jun 2005 06:37:51 +0000 (GMT) (envelope-from ru@ip.net.ua) Received: from localhost (rocky.ip.net.ua [82.193.96.2]) by tigra.ip.net.ua (8.12.11/8.12.11) with ESMTP id j536bkhj070086; Fri, 3 Jun 2005 09:37:46 +0300 (EEST) (envelope-from ru@ip.net.ua) Received: from tigra.ip.net.ua ([82.193.96.10]) by localhost (rocky.ipnet [82.193.96.2]) (amavisd-new, port 10024) with LMTP id 52866-01; Fri, 3 Jun 2005 09:37:45 +0300 (EEST) Received: from heffalump.ip.net.ua (heffalump.ip.net.ua [82.193.96.213]) by tigra.ip.net.ua (8.12.11/8.12.11) with ESMTP id j536bj5o070083 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 3 Jun 2005 09:37:45 +0300 (EEST) (envelope-from ru@ip.net.ua) Received: (from ru@localhost) by heffalump.ip.net.ua (8.13.3/8.13.3) id j536Dwqq050792; Fri, 3 Jun 2005 09:13:58 +0300 (EEST) (envelope-from ru) Date: Fri, 3 Jun 2005 09:13:58 +0300 From: Ruslan Ermilov To: Craig Rodrigues Message-ID: <20050603061357.GB50672@ip.net.ua> References: <20050603022444.GA34086@crodrigues.org> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="JP+T4n/bALQSJXh8" Content-Disposition: inline In-Reply-To: <20050603022444.GA34086@crodrigues.org> User-Agent: Mutt/1.5.9i X-Virus-Scanned: by amavisd-new at ip.net.ua Cc: freebsd-fs@freebsd.org, dumbbell@freebsd.org, freebsd-arch@freebsd.org Subject: Re: [RFC] Move reiserfs code to src/sys/gnu/fs? 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, 03 Jun 2005 06:37:52 -0000 --JP+T4n/bALQSJXh8 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Thu, Jun 02, 2005 at 10:24:44PM -0400, Craig Rodrigues wrote: > Hi, >=20 > Due to the increasing number of filesystems with GNU licenses > being imported into the tree (Reiserfs was just imported, and > sometime in the future, XFS may be imported), I suggest > that a new directory be created: >=20 > src/sys/gnu/fs >=20 > I also suggest that the recent Reiserfs code which was imported > into the tree be moved from > src/sys/gnu/reiserfs to src/sys/gnu/fs/reiserfs >=20 > Since the code was just imported, this operation should be > a simple case of cvs rm'ing the files that exist, and cvs add'ing > them to the new directory. >=20 > At some point, it would be nice to move ext2fs to > src/sys/gnu/fs, but that would involve more work (a repo copy). >=20 > What do people think? >=20 This would be in line with what I did with sys/fs/ at the time. Good idea. Cheers, --=20 Ruslan Ermilov ru@FreeBSD.org FreeBSD committer --JP+T4n/bALQSJXh8 Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.1 (FreeBSD) iD8DBQFCn/UlqRfpzJluFF4RAiRbAKCdFlmkO8Tk66kTX1yqp7ayIahrnQCcDuZY bsQJU8QzyHjcWOjuuDvv2JA= =B95a -----END PGP SIGNATURE----- --JP+T4n/bALQSJXh8-- From owner-freebsd-fs@FreeBSD.ORG Fri Jun 3 10:35:50 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 4A1D616A41C; Fri, 3 Jun 2005 10:35:50 +0000 (GMT) (envelope-from jspedron@club-internet.fr) Received: from smtp.cegetel.net (mf01.sitadelle.com [212.94.174.80]) by mx1.FreeBSD.org (Postfix) with ESMTP id E65E143D49; Fri, 3 Jun 2005 10:35:49 +0000 (GMT) (envelope-from jspedron@club-internet.fr) Received: from [172.16.142.1] (213-223-184-193.dti.cegetel.net [213.223.184.193]) by smtp.cegetel.net (Postfix) with ESMTP id 8DA2D31837B; Fri, 3 Jun 2005 12:35:48 +0200 (CEST) Message-ID: <42A03288.8080608@club-internet.fr> Date: Fri, 03 Jun 2005 12:35:52 +0200 From: =?ISO-8859-1?Q?Jean-S=E9bastien_P=E9dron?= User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.8a6) Gecko/20050208 X-Accept-Language: fr-fr, fr, en-us, en, ja MIME-Version: 1.0 To: Craig Rodrigues References: <20050603022444.GA34086@crodrigues.org> In-Reply-To: <20050603022444.GA34086@crodrigues.org> X-Enigmail-Version: 0.90.0.0 X-Enigmail-Supports: pgp-inline, pgp-mime Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="------------enig432660CADC0F7FCCDF1D3736" Content-Transfer-Encoding: 8bit Cc: freebsd-fs@freebsd.org, freebsd-arch@freebsd.org Subject: Re: [RFC] Move reiserfs code to src/sys/gnu/fs? 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, 03 Jun 2005 10:35:50 -0000 This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --------------enig432660CADC0F7FCCDF1D3736 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit Craig Rodrigues wrote: > Hi, > > Due to the increasing number of filesystems with GNU licenses > being imported into the tree (Reiserfs was just imported, and > sometime in the future, XFS may be imported), I suggest > that a new directory be created: > > src/sys/gnu/fs > > I also suggest that the recent Reiserfs code which was imported > into the tree be moved from > src/sys/gnu/reiserfs to src/sys/gnu/fs/reiserfs > > Since the code was just imported, this operation should be > a simple case of cvs rm'ing the files that exist, and cvs add'ing > them to the new directory. > > At some point, it would be nice to move ext2fs to > src/sys/gnu/fs, but that would involve more work (a repo copy). > > What do people think? I'm ok with this change too. -- Jean-Sébastien Pédron http://www.dumbbell.fr/ PGP Key: http://www.dumbbell.fr/pgp/pubkey.asc --------------enig432660CADC0F7FCCDF1D3736 Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.5 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFCoDKLa+xGJsFYOlMRAnnxAKCkONEnCQSbFisz46/tPk9z2PNWoQCfY/as tGCB/zb3/hgy6XV/qyJho6Y= =ac38 -----END PGP SIGNATURE----- --------------enig432660CADC0F7FCCDF1D3736--