Questions about btrfs helper threads

[Valdis.Kletnieks at vt.edu]

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.


-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 848 bytes
Desc: not available
Url : http://lists.kernelnewbies.org/pipermail/kernelnewbies/attachments/20140824/6ceb1cc7/attachment.bin