All of lore.kernel.org
 help / color / mirror / Atom feed
From: Austin S Hemmelgarn <ahferroin7@gmail.com>
To: Toggenburger Lukas <Lukas.Toggenburger@htwchur.ch>,
	"linux-btrfs@vger.kernel.org" <linux-btrfs@vger.kernel.org>
Subject: Re: Working on Btrfs as topic for master thesis
Date: Mon, 20 Jan 2014 07:20:30 -0500	[thread overview]
Message-ID: <52DD148E.3060200@gmail.com> (raw)
In-Reply-To: <8E968DF3B7EC0D40B67B5A9D25675A6A03FC70@MBXSRV03EDU.edu.local>

On 2014-01-16 14:23, Toggenburger Lukas wrote:
> Hi all
> 
> I'm a student of ICT currently doing my master's degree besides working as a research assistant. Currently I'm looking for topics for my master thesis. One of my ideas was to work on Btrfs. I studied the list of project ideas at https://btrfs.wiki.kernel.org/index.php/Project_ideas and am especially interested in working on one of the following topics:
> 
> 1. (Enhanced) hot spare support as described in https://btrfs.wiki.kernel.org/index.php/Project_ideas#Hot_spare_support and https://btrfs.wiki.kernel.org/index.php/Project_ideas#.22Enhanced.22_.28ala_RAID.29_support
> 
> 2. Adding more checksumming algorithms ( https://btrfs.wiki.kernel.org/index.php/Project_ideas#More_checksumming_algorithms )
> 
> 3. Improving subvolume handling regarding taking recursive snapshots ( https://btrfs.wiki.kernel.org/index.php/Project_ideas#Take_recursive_snapshots ) and taking snapshots of arbitrary directories ( https://btrfs.wiki.kernel.org/index.php/Project_ideas#Snapshot_arbitrary_directories )

Another option that I would personally love to see would be support for
write-mostly devices (that is, devices in a RAID1/RAID10 setup that only
get written too unless the data can't be found elsewhere).  This would
in particular provide an alternative to using bcache/dm-cache (namely an
SSD and HDD in RAID1 with the HDD set to write-mostly).
Based on the current development focus, I don't think anybody is working
on this already (I would be, but I don't have either the time or the
skills with kernel programming that would be needed).



  parent reply	other threads:[~2014-01-20 12:27 UTC|newest]

Thread overview: 18+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2014-01-16 19:23 Working on Btrfs as topic for master thesis Toggenburger Lukas
2014-01-17 15:34 ` David Sterba
2014-01-17 16:04 ` Tomasz Torcz
2014-01-18 12:50   ` Toggenburger Lukas
2014-01-22 12:05     ` David Sterba
2014-01-22 13:35       ` Hugo Mills
2014-01-20  5:44 ` Roger Binns
2014-01-22 12:12   ` David Sterba
2014-01-22 20:55     ` Roger Binns
2014-01-23 18:36       ` David Sterba
2014-01-23 21:47         ` Roger Binns
2014-01-20 12:20 ` Austin S Hemmelgarn [this message]
2014-01-21  6:42   ` Sandy McArthur
2014-01-21 12:25     ` Austin S Hemmelgarn
2014-01-21 16:52       ` Hugo Mills
2014-01-21 16:59         ` Austin S Hemmelgarn
2014-01-22 12:20         ` David Sterba
2014-01-22 12:24           ` David Sterba

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=52DD148E.3060200@gmail.com \
    --to=ahferroin7@gmail.com \
    --cc=Lukas.Toggenburger@htwchur.ch \
    --cc=linux-btrfs@vger.kernel.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.