Thread (3 messages) 3 messages, 2 authors, 2014-08-25

Questions about btrfs helper threads

From: nick <hidden>
Date: 2014-08-25 02:21:12

Possibly related (same subject, not in this thread)


On 14-08-24 11:22 AM, Valdis.Kletnieks at vt.edu wrote:
On Sun, 24 Aug 2014 01:49:07 -0400, nick said:
quoted
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   
Keyboard shortcuts
hback out one level
jnext message in thread
kprevious message in thread
ldrill in
Escclose help / fold thread tree
?toggle this help