Date: Tue, 7 Jul 2009 09:36:42 -0700 (PDT) From: Matthew Dillon <dillon@apollo.backplane.com> To: Alexander Motin <mav@FreeBSD.org> Cc: freebsd-arch@FreeBSD.org Subject: Re: DFLTPHYS vs MAXPHYS Message-ID: <200907071636.n67GagxN087660@apollo.backplane.com> References: <1246746182.00135530.1246735202@10.7.7.3> <1246792983.00135712.1246781401@10.7.7.3> <1246796580.00135722.1246783203@10.7.7.3> <1246814582.00135806.1246803602@10.7.7.3> <1246818181.00135809.1246804804@10.7.7.3> <1246825383.00135846.1246812602@10.7.7.3> <1246825385.00135854.1246814404@10.7.7.3> <1246830930.00135868.1246819202@10.7.7.3> <1246830933.00135875.1246820402@10.7.7.3> <1246908182.00136258.1246896003@10.7.7.3> <1246911786.00136277.1246900203@10.7.7.3> <1246915383.00136290.1246904409@10.7.7.3> <4A534D05.1040709@FreeBSD.org>
next in thread | previous in thread | raw e-mail | index | archive | help
:You are mixing completely different things. I was never talking about :file system block size. I am not trying to argue that 16/32K file system :block size may be quite effective in most of cases. I was speaking about :maximum _disk_transaction_ size. It is not the same. : :When file system needs small amount of data, or there is just small :file, there is definitely no need to read/write more then one small FS :block. But instead, when file system prognoses effective large :read-ahead or it have a lot of write-back data, there is no reason to :not transfer more contiguous blocks with one big disk transaction. :Splitting it will just increase command overhead at all layers and make :possible drive to be interrupted between that operations to do some very :long seek. :-- :Alexander Motin That isn't correct. Locality of reference for adjacent data is very important even if the filesystem only needs a small amount of data. A good example of this would be accessing the inode area in a UFS cylinder. Issuing only a single filesystem block read in the inode area is a huge lose verses issueing a cluster read of 64K (4-8 filesystem blocks), particularly if the inode is being accessed as part of a 'find' or 'ls -lR'. I have not argued that the maximum device block size is important, I've simply argued that it is convenient. What is important, and I stressed this in my argument several times, is the total number of bytes the cluster_read() code reads when the filesystem requests a particular filesystem block. -Matt Matthew Dillon <dillon@backplane.com>
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?200907071636.n67GagxN087660>