From 67aa53a1e17e7d94ccbc244476fa6ce7b6b968d2 Mon Sep 17 00:00:00 2001 From: Jeremy Allison Date: Mon, 28 Mar 2011 14:12:36 -0700 Subject: Be a little clearer about when and when not to set this option. Autobuild-User: Jeremy Allison Autobuild-Date: Mon Mar 28 23:59:47 CEST 2011 on sn-devel-104 --- docs-xml/smbdotconf/tuning/strictallocate.xml | 12 ++++++++---- 1 file changed, 8 insertions(+), 4 deletions(-) (limited to 'docs-xml/smbdotconf/tuning') diff --git a/docs-xml/smbdotconf/tuning/strictallocate.xml b/docs-xml/smbdotconf/tuning/strictallocate.xml index 1855574776..900c90f215 100644 --- a/docs-xml/smbdotconf/tuning/strictallocate.xml +++ b/docs-xml/smbdotconf/tuning/strictallocate.xml @@ -9,10 +9,14 @@ disk storage blocks when a file is extended to the Windows behaviour of actually forcing the disk system to allocate real storage blocks when a file is created or extended to be a given size. In UNIX - terminology this means that Samba will stop creating sparse files. - This can be slow on some systems. When you work with large files like - >100MB or so you may even run into problems with clients running into - timeouts. + terminology this means that Samba will stop creating sparse files. + + This option is really desgined for file systems that support + fast allocation of large numbers of blocks such as extent-based file systems. + On file systems that don't support extents (most notably ext3) this can + make Samba slower. When you work with large files over >100MB on file + systems without extents you may even run into problems with clients + running into timeouts. When you have an extent based filesystem it's likely that we can make use of unwritten extents which allows Samba to allocate even large amounts -- cgit