Date: Tue, 10 Feb 2004 10:31:15 -0800 From: Mark Day <mday@apple.com> To: Ion-Mihai Tetcu <itetcu@apropo.ro> Cc: freebsd-fs@freebsd.org Subject: Re: Painful speed for copying to fat32 partitions with small cluster size. Message-ID: <4F987C5C-5BF7-11D8-A867-00039354009A@apple.com> In-Reply-To: <20040207155819.186335d4@it.buh.cameradicommercio.ro> References: <20040207155819.186335d4@it.buh.cameradicommercio.ro>
next in thread | previous in thread | raw e-mail | index | archive | help
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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?4F987C5C-5BF7-11D8-A867-00039354009A>