Re: Work Queue for btrfs compression writes

From: Hugo Mills
Date: Wed Jul 30 2014 - 05:38:29 EST

On Tue, Jul 29, 2014 at 11:54:20PM -0400, Nick Krause wrote:
> Hey Guys ,
> I am new to reading and writing kernel code.I got interested in
> writing code for btrfs as it seems to
> need more work then other file systems and this seems other then
> drivers, a good use of time on my part.
> I interested in helping improving the compression of btrfs by using a
> set of threads using work queues like XFS
> or reads and keeping the page cache after reading compressed blocks as
> these seem to be a great way to improve
> on compression performance mostly with large partitions of compressed
> data. I am not asking you to write the code
> for me but as I am new a little guidance and help would be greatly
> appreciated as this seems like too much work for just a newbie.

* Documentation/workqueue.txt (in general, grep in Documentation
usually throws up something useful)

* grep -r alloc_workqueue fs/ shows a lot of uses (including in
btrfs), so it should be fairly easy to see how to create and manage
a workqueue.

I suspect that this may be a medium-sized project, rather than a
small one. My gut feeling (based on limited experience) is that the
fallocate extensions project would be considerably simpler.

I also noticed from the public reply to the private mail (don't do
this without getting permission from the other person) that you posted
to LKML in this thread (don't switch mailing lists mid-thread) that
you anticipated having problems testing with limited disks -- what you
will find is that testing new kernel code is something that you don't
do on your main development OS installation. Instead, you will need
either a scratch machine that you can easily update, or one or more
virtual machines. qemu/kvm is good for this, because it has a mode
that bypasses the BIOS and bootloader emulation, and just directly
runs a kernel from a file on the host machine. This is fast. You can
pass large sparse files to the VM to act as scratch disks, plus keep
another smaller file for the guest OS (and a copy of it so that you
can throw one away and make another one quickly and easily).


=== Hugo Mills: hugo@... | | ===
PGP key: 65E74AC0 from or
--- You've read the project plan. Forget that. We're going to Do ---
Stuff and Have Fun doing it.

Attachment: signature.asc
Description: Digital signature