From owner-freebsd-fs@FreeBSD.ORG Fri Oct 30 07:06:16 2009 Return-Path: Delivered-To: freebsd-fs@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 0AFF2106566B for ; Fri, 30 Oct 2009 07:06:16 +0000 (UTC) (envelope-from alexz@visp.ru) Received: from mail.visp.ru (srv1.visp.ru [91.215.204.2]) by mx1.freebsd.org (Postfix) with ESMTP id B7AF28FC1A for ; Fri, 30 Oct 2009 07:06:15 +0000 (UTC) Received: from 91-215-205-255.static.visp.ru ([91.215.205.255] helo=zagrebin) by mail.visp.ru with esmtp (Exim 4.66 (FreeBSD)) (envelope-from ) id 1N3lJk-000FGJ-5h for freebsd-fs@freebsd.org; Fri, 30 Oct 2009 09:50:36 +0300 From: "Alexander Zagrebin" To: Date: Fri, 30 Oct 2009 09:50:36 +0300 Message-ID: <656C9ACD24DB41898D89F64DC7A2E3E1@vosz.local> MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="----=_NextPart_000_05E8_01CA5946.6E064D50" X-Mailer: Microsoft Office Outlook 11 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.5512 Thread-Index: AcpZLUiLsEB5lpgQSPezD2IUr6TQ5w== Subject: ZFS statfs problem X-BeenThere: freebsd-fs@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Filesystems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 30 Oct 2009 07:06:16 -0000 This is a multi-part message in MIME format. ------=_NextPart_000_05E8_01CA5946.6E064D50 Content-Type: text/plain; charset="koi8-r" Content-Transfer-Encoding: 7bit Hi! I have noticed, that statfs called for ZFS file systems, returns the value of fs's recordsize property in both f_bsize and f_iosize. It's a problem for some software. For example, squid uses block size of cache's file system to calculate the space occupied by file. So it considers that any small file uses 128KB of a cache (when default value of recordsize is used), though really this file may use 512B only. This miscalculation generates unjustified cleaning of a cache. There are the some possible solutions: - to set recordsize to lower value (for example, 2K), but it's not optimal for file system. - to force squid to use 512 as block size (via patch) - to change the zfs code (zfs_vfsops.c) to return 512 as f_bsize and recordsize as f_iosize (see attached patch for 8.0-RC1) I think that the last solution is more correct. The patch seems to be working, but i'm not sure that it's correct. Would you comment this? -- Alexander Zagrebin ------=_NextPart_000_05E8_01CA5946.6E064D50 Content-Type: application/octet-stream; name="patch-zfs_vfsops.c" Content-Transfer-Encoding: quoted-printable Content-Disposition: attachment; filename="patch-zfs_vfsops.c" --- sys/cddl/contrib/opensolaris/uts/common/fs/zfs/zfs_vfsops.c.orig = 2009-09-29 14:53:06.000000000 +0400=0A= +++ sys/cddl/contrib/opensolaris/uts/common/fs/zfs/zfs_vfsops.c = 2009-10-26 15:47:29.365783209 +0300=0A= @@ -214,7 +214,7 @@=0A= newval =3D SPA_MAXBLOCKSIZE;=0A= =0A= zfsvfs->z_max_blksz =3D newval;=0A= - zfsvfs->z_vfs->vfs_bsize =3D newval;=0A= + zfsvfs->z_vfs->mnt_stat.f_iosize =3D newval;=0A= }=0A= =0A= static void=0A= @@ -577,7 +577,8 @@=0A= if (error =3D dsl_prop_get_integer(osname, "recordsize", &recordsize,=0A= NULL))=0A= goto out;=0A= - zfsvfs->z_vfs->vfs_bsize =3D recordsize;=0A= + zfsvfs->z_vfs->vfs_bsize =3D SPA_MINBLOCKSIZE;=0A= + zfsvfs->z_vfs->mnt_stat.f_iosize =3D recordsize;=0A= =0A= vfsp->vfs_data =3D zfsvfs;=0A= vfsp->mnt_flag |=3D MNT_LOCAL;=0A= @@ -817,8 +818,8 @@=0A= * We report the fragsize as the smallest block size we support,=0A= * and we report our blocksize as the filesystem's maximum blocksize.=0A= */=0A= - statp->f_bsize =3D zfsvfs->z_vfs->vfs_bsize;=0A= - statp->f_iosize =3D zfsvfs->z_vfs->vfs_bsize;=0A= + statp->f_bsize =3D SPA_MINBLOCKSIZE;=0A= + statp->f_iosize =3D zfsvfs->z_vfs->mnt_stat.f_iosize;=0A= =0A= /*=0A= * The following report "total" blocks of various kinds in the=0A= ------=_NextPart_000_05E8_01CA5946.6E064D50--