From owner-freebsd-fs@FreeBSD.ORG Tue Feb 10 10:33:20 2004 Return-Path: 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 3BBF216A4CE for ; Tue, 10 Feb 2004 10:33:20 -0800 (PST) Received: from mail-out3.apple.com (mail-out3.apple.com [17.254.13.22]) by mx1.FreeBSD.org (Postfix) with ESMTP id 3396C43D1F for ; Tue, 10 Feb 2004 10:33:20 -0800 (PST) (envelope-from mday@apple.com) Received: from mailgate1.apple.com (a17-128-100-225.apple.com [17.128.100.225]) by mail-out3.apple.com (8.12.11/8.12.11) with ESMTP id i1AIXJ2j018922 for ; Tue, 10 Feb 2004 10:33:19 -0800 (PST) Received: from relay3.apple.com (relay3.apple.com) by mailgate1.apple.com ; Tue, 10 Feb 2004 10:33:19 -0800 Received: from [17.202.44.244] (daylight.apple.com [17.202.44.244]) by relay3.apple.com (8.12.11/8.12.11) with ESMTP id i1AIXFSX027228; Tue, 10 Feb 2004 18:33:16 GMT In-Reply-To: <20040207155819.186335d4@it.buh.cameradicommercio.ro> References: <20040207155819.186335d4@it.buh.cameradicommercio.ro> Mime-Version: 1.0 (Apple Message framework v612) Content-Type: text/plain; charset=US-ASCII; format=flowed Message-Id: <4F987C5C-5BF7-11D8-A867-00039354009A@apple.com> Content-Transfer-Encoding: 7bit From: Mark Day Date: Tue, 10 Feb 2004 10:31:15 -0800 To: Ion-Mihai Tetcu X-Mailer: Apple Mail (2.612) cc: freebsd-fs@freebsd.org Subject: Re: Painful speed for copying to fat32 partitions with small cluster size. X-BeenThere: freebsd-fs@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Filesystems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 10 Feb 2004 18:33:20 -0000 On Feb 7, 2004, at 5:58 AM, Ion-Mihai Tetcu wrote: > Copying to FAT32 partitions is very slow with small cluster sizes (I > was > copying some 300 - 700MB files): (My FAT experience is mostly from Darwin/Mac OS X, which was ported from FreeBSD a few years ago. I haven't looked at the FreeBSD sources recently to know how relevant these remarks are for FreeBSD). First of all, smaller clusters sizes means larger FAT tables (more entries per table). This means you end up doing more I/O for a given file size. The Darwin code as originally ported from FreeBSD was using buffer cache blocks sized the same as a cluster (that is, one cluster per buffer cache block). But the real problem was that the VOP_BMAP (and VOP_CMAP in Darwin) implementation was very naive and always claimed that only there were no additional blocks of the file contiguous with the one being mapped. So, read and write ended up doing lots of tiny maps and I/Os. When this was fixed to scan the FAT for contiguous clusters, the buffer cache code (what Darwin calls Cluster I/O) was able to send much larger I/O requests to the driver. This made a huge difference, and brought streaming I/O performance into line with HFS Plus and UFS. -Mark