Date: Wed, 16 May 2001 19:57:05 +1000 (EST) From: Bruce Evans <bde@zeta.org.au> To: Stefan Parvu <sparvu@cc.hut.fi> Cc: freebsd-fs@FreeBSD.ORG, fbsdq@yahoo.com Subject: Re: UFS to FAT32 Message-ID: <Pine.BSF.4.21.0105161918520.8593-100000@besplex.bde.org> In-Reply-To: <Pine.OSF.4.10.10105152219110.24386-100000@alpha.hut.fi>
next in thread | previous in thread | raw e-mail | index | archive | help
On Tue, 15 May 2001, Stefan Parvu wrote: > I tested FreeBSD 4.3-RELEASE doing this : > > 1. mount /win98 partition as rw only. Move from BSD partition to FAT32 a > file of 500MB. Time around 25min. System really slow. CPU as idle around > 99% but vmstat reported a lot of blocked processes(2to6). Can't work > anymore in the box until de copy operation finished. This is probably caused by new (in 4.3) default of write caching turned off for ATA drives. I'm not sure why it blocks so many processes. It should only make the system unusable when many processes other than the copy hog want to access the disk :-]. > 2. mount /win98 as rw, sync. The same scenario movinf a file 500MB from > UFS to FAT32 . Time around 35min. System ok. You can do some other work > meanwhile copy operation. In the first scenario there were really long > delays until opening a new terminal, or top, whatever processes. Interesting. The sync mount option make all writes of data blocks to the disk synchronous. It has no effect on the synchronicity of writes of metadata blocks at least for ffs, which is not where the writes are here, but msdosfs shouldn't be much different. (A quick check shows that FAT updates are not properly synced by default, but the sync option bogusly fixes this -- the sync option is only supposed to affect data writes. Syncing of the FAT should default to on and be controlled by the (currently unimplemented for msdosfs) async mount option. The only other related brokenness seems to be that the sync option doesn't give syncing of new data blocks in extendfile().) Anyway, the sync mount option is usually just a pessimization. It must be reducing the long delays by reducing the size of the average i/o. With the sync option, the system writes data blocks immediately, with a block size identical to the filesystem block size. Without it, blocks are clustered, and the average block size seen by the driver should be close to its maximum (128K for ATA disks) since the file is large. Writing a 128K block doesn't take all that long since your disk has a bandwidth of 20+-37MB/sec, but it is apparently too long to suit the clustering code. Bruce To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-fs" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?Pine.BSF.4.21.0105161918520.8593-100000>