Hi, I ported exfat fuse module to FreeBSD (PR 164473) and found that it works much slower then on Linux. I found 2 reasons for this: 1) FreeBSD kernel do not allow to have nonalignment access to device with standard read/write commands. mmap to the entire disk (/dev/da0s1) doesn`t work also (EINVAL). When its not a big deal for read requests, for write it becomes a real issue - to write non-aligned data i need to read beginning and end of the block. So in fact for one write request i can get 2 reads. 2) It seems that there is a very simple read caching on such devices without write caching at all. It makes write performance enormously slow. I found geom_cache module, but it provides only read optimization. I decided to compare speed on Linux and FreeBSD and below are my results. I used old USB flash drive to do the tests. Read Speed of 100Mb: Linux 3.0.0: 22.7 Mb/sec FreeBSD: 10.22 Mb/sec FreeBSD + gcache: 18.75 Mb/sec (!) Write speed of 100Mb file: Linux: 90Mb/sec (cache, much higher then device speed) FreeBSD: 0.52 Mb/sec (!) FreeBSD + gcache: 0.52 Mb/sec As you could see write performance is enormously slow. May be we need to create some geom provider for such caching or i am missing something? I think, that other fuse modules like ntfs-3g and fuse-ext4 having same issue. Also i found that fuse4bsd itself is non stable and may crash the system without any visible reasons.
schrieb Alex Samorukov am 26.01.2012 14:52 (localtime):> Hi, > > I ported exfat fuse module to FreeBSD (PR 164473) and found that it > works much slower then on Linux. I found 2 reasons for this: >Thanks a lot! I saw the new port :-) Hope that someone can help you improove fusefs-kmod. I remember more porters were blaming FreeBSDs fusefs support making their work hard/impossible (TrueCrypt). Hopefully some kernel hacker will read and help... Best regards, -Harry> 1) FreeBSD kernel do not allow to have nonalignment access to device > with standard read/write commands. mmap to the entire disk > (/dev/da0s1) doesn`t work also (EINVAL). > > When its not a big deal for read requests, for write it becomes a real > issue - to write non-aligned data i need to read beginning and end of > the block. So in fact for one write request i can get 2 reads. > > 2) It seems that there is a very simple read caching on such devices > without write caching at all. It makes write performance enormously > slow. I found geom_cache module, but it provides only read optimization. > > > I decided to compare speed on Linux and FreeBSD and below are my > results. I used old USB flash drive to do the tests. > > Read Speed of 100Mb: > > Linux 3.0.0: 22.7 Mb/sec > FreeBSD: 10.22 Mb/sec > FreeBSD + gcache: 18.75 Mb/sec (!) > > Write speed of 100Mb file: > Linux: 90Mb/sec (cache, much higher then device speed) > FreeBSD: 0.52 Mb/sec (!) > FreeBSD + gcache: 0.52 Mb/sec > > As you could see write performance is enormously slow. May be we need > to create some geom provider for such caching or i am missing > something? I think, that other fuse modules like ntfs-3g and fuse-ext4 > having same issue. Also i found that fuse4bsd itself is non stable and > may crash the system without any visible reasons. > _______________________________________________ > freebsd-stable@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-stable > To unsubscribe, send any mail to "freebsd-stable-unsubscribe@freebsd.org"-------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 196 bytes Desc: OpenPGP digital signature Url : http://lists.freebsd.org/pipermail/freebsd-stable/attachments/20120131/cc7b9cf2/signature.pgp
On 01/31/2012 11:19 AM, Harald Schmalzbauer wrote:> schrieb Alex Samorukov am 26.01.2012 14:52 (localtime): >> Hi, >> >> I ported exfat fuse module to FreeBSD (PR 164473) and found that it >> works much slower then on Linux. I found 2 reasons for this: >> > Thanks a lot! I saw the new port :-) > Hope that someone can help you improove fusefs-kmod. I remember more > porters were blaming FreeBSDs fusefs support making their work > hard/impossible (TrueCrypt). Hopefully some kernel hacker will read and > help...Thank you for comment. It is now mostly not about fuse itself, but about non-buffered raw device access. I really think that something like improved geom_cache should solve this. I`ll add soon updated version of the patch with [optional] libublio support. This improves performance a lot. Read speed is comparable with Linux (about 20 Mb/sec on my old USB) and write is much faster aw well (but not so good as in Linux and with a lot read requests for align). Also i contacted upstream about unaligned writes and he told that it is in his todo list, but probably after 1.0.0 version, because it will require a lot of changes in the code. Also i found a libexfat bug in a fat time handling and creating patch to use freebsd code for this instead. So if you are using exfat any testing and comments are welcome.
Hi, What about the disk access is unaligned? Do you mean not sector aligned? or? This is a common problem people face doing disk IO analysis. The whole point about not allowing unaligned access is to make the disk IO path cleaner. It does mean that the filesystem code (and GEOM modules involved) need to be smarter. If the filesystem is doing ridiculously unaligned access then it likely should be fixed. Adrian
On 02/12/2012 01:54 AM, Adrian Chadd wrote:> Hi, > > What about the disk access is unaligned? Do you mean not sector aligned? or?Hi. Sector aligned.> This is a common problem people face doing disk IO analysis. > > The whole point about not allowing unaligned access is to make the > disk IO path cleaner. It does mean that the filesystem code (and GEOM > modules involved) need to be smarter. > > If the filesystem is doing ridiculously unaligned access then it > likely should be fixed.Yes. But it will nit fix non-cached access to the disk (raw) devices. And this is the main reason why ntfs-3g and exfat are much slower then working on Linux.
On Wed, Feb 15, 2012 at 12:27:19AM -0600, Adam Vande More wrote:> On Tue, Feb 14, 2012 at 10:50 PM, Scott Long <scottl@samsco.org> wrote: > > > > > Any filesystem that uses bread/bwrite/cluster_read are already using the > > "generic caching subsystem" that you propose. This includes UDF, CD9660, > > MSDOS, NTFS, XFS, ReiserFS, EXT2FS, and HPFS, i.e. every local storage > > filesystem in the tree except for ZFS. Not all of them implement > > VOP_GETPAGES/VOP_PUTPAGES, but those are just optimizations for the vnode > > pager, not requirements for using buffer-cache services on block devices. > > As Kostik pointed out in a parallel email, the only thing that was removed > > from FreeBSD was the userland interface to cached devices via /dev nodes. > > > > Does this mean the Architecture Handbook page is wrong?: > > http://www.freebsd.org/doc/en/books/arch-handbook/driverbasics-block.htmlNo, why did you decided that it is wrong ? -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 196 bytes Desc: not available Url : http://lists.freebsd.org/pipermail/freebsd-stable/attachments/20120215/64bbedfd/attachment.pgp