Questions about btrfs helper threads

[nick]

On 14-08-24 11:22 AM, Valdis.Kletnieks at vt.edu wrote:
> On Sun, 24 Aug 2014 01:49:07 -0400, nick said:
>> After searching through parts of the btrfs code and docs. I am unable to find any information
>> on the helper threads in btrfs and would like to known more about how their implemented and
>> what are the reasons for helper threads in btrfs versus only 1 for journaling in ext3/ext3.
> 
> Really?  *REALLY*?  You can't find anything?  What searching did you *DO*?
> 
> [~] cd /usr/src/linux-next/
> [/usr/src/linux-next] ls fs/btrfs
> Kconfig         btrfs_inode.h      delayed-ref.h  extent-tree.o       hash.c        locking.o       props.h       root-tree.o     transaction.c  volumes.h
> Makefile        built-in.o         delayed-ref.o  extent_io.c         hash.h        lzo.c           props.o       scrub.c         transaction.h  volumes.o
> acl.c           check-integrity.c  dev-replace.c  extent_io.h         hash.o        lzo.o           qgroup.c      scrub.o         transaction.o  xattr.c
> acl.o           check-integrity.h  dev-replace.h  extent_io.o         inode-item.c  math.h          qgroup.h      send.c          tree-defrag.c  xattr.h
> async-thread.c  compression.c      dev-replace.o  extent_map.c        inode-item.o  modules.order   qgroup.o      send.h          tree-defrag.o  xattr.o
> async-thread.h  compression.h      dir-item.c     extent_map.h        inode-map.c   ordered-data.c  raid56.c      send.o          tree-log.c     zlib.c
> async-thread.o  compression.o      dir-item.o     extent_map.o        inode-map.h   ordered-data.h  raid56.h      struct-funcs.c  tree-log.h     zlib.o
> backref.c       ctree.c            disk-io.c      file-item.c         inode-map.o   ordered-data.o  raid56.o      struct-funcs.o  tree-log.o
> backref.h       ctree.h            disk-io.h      file-item.o         inode.c       orphan.c        rcu-string.h  super.c         ulist.c
> backref.o       ctree.o            disk-io.o      file.c              inode.o       orphan.o        reada.c       super.o         ulist.h
> btrfs.ko        delayed-inode.c    export.c       file.o              ioctl.c       print-tree.c    reada.o       sysfs.c         ulist.o
> btrfs.mod.c     delayed-inode.h    export.h       free-space-cache.c  ioctl.o       print-tree.h    relocation.c  sysfs.h         uuid-tree.c
> btrfs.mod.o     delayed-inode.o    export.o       free-space-cache.h  locking.c     print-tree.o    relocation.o  sysfs.o         uuid-tree.o
> btrfs.o         delayed-ref.c      extent-tree.c  free-space-cache.o  locking.h     props.c         root-tree.c   tests           volumes.c
> 
> Now take a look there in the left-hand column.  You *might* find
> something useful there.
> 
> As to the rest of your question, the ext filesystems have as a design goal
> good performance on 1-2 core machines, while btrfs was designed to take
> advantage of high-core-count machines. Hopefully you're a good enough
> programmer that I don't have to explain further.
> 
> 
Thanks for the answers and yes, I was searching in the wiki , not the tree sorry :( fucking brain fart). Thanks for information , in addition , when you mean multiple cores I am curious how many is btrfs scaling to in order to help me understand the locking requirements and more demanding locking I am finding in the btrfs code.
Thanks Again for the Help,
Nick