| lists.openwall.net | lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC | |
|
Open Source and information security mailing list archives
| ||
|
Message-Id: <1157468114.1435.216.camel@capoeira> Date: Tue, 05 Sep 2006 16:55:14 +0200 From: Xavier Bestel <xavier.bestel@...e.fr> To: Mattias Rönnblom <hofors@...ator.liu.se> Cc: linux-kernel@...r.kernel.org Subject: Re: VFAT truncate performance On Tue, 2006-09-05 at 15:52, Mattias Rönnblom wrote: > Hi, > > extending files by ftruncate(2) runs very slow on VFAT file > systems. On my USB harddisk w/ VFAT, it takes 14 seconds to extend an > empty file to 1 GB. On a memory stick, it takes well over 4 minutes. > > My question is: is this problem on the conceptual level (ie there is > no way of extending files on FAT that doesn't involve many disk > operations) or is the current Linux fs driver suboptimal in this > respect? > > The reason for asking is that I run Samba which service files on USB > devices (w/ VFAT for portability) to Windows XP clients. When copying > files to the Samba server, Microsoft SMB clients seem to extend the > file before actually starting to copy the data. This results in > sluggishness and timeouts when copying large files to VFAT > filesystems. Is your USB stick mounted -o sync ? If that's the case, the truncate() and write() won't be merged so they will take twice as long. -o sync generally kills performance on USB sticks. Xav - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@...r.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Powered by blists - more mailing lists