From: Subrata Modak <subrata@linux.vnet.ibm.com>
To: Josef Bacik <josef@redhat.com>
Cc: ltp-list <ltp-list@lists.sf.net>, linux-btrfs@vger.kernel.org
Subject: Re: [LTP] Btrfs TODO
Date: Mon, 13 Apr 2009 18:44:08 +0530 [thread overview]
Message-ID: <1239628449.16922.18.camel@subratamodak.linux.ibm.com> (raw)
In-Reply-To: <1239345763.5029.18.camel@subratamodak.linux.ibm.com>
Hi Josef,
On Fri, 2009-04-10 at 12:12 +0530, Subrata Modak wrote:
> Hi Josef,
>
> On Thu, 2009-04-09 at 12:24 -0400, Josef Bacik wrote:
> > Hello,
> >
> > Trying to put together a list of TODO items for btrfs so we can update the wiki
> > page fully. So far these things are on the list
> >
> > * Proper ENOSPC handling
> > * O_DIRECT support (without checksumming)
> > * AIO support
> > * Subvolume quotas and inherited space usage information
> > * Snapshot removal
> > * QA Suite for automated regression testing
>
> We at LTP would be interested in the above. Please let us know your
> plans in doing Btrfs testing in any ways you do.
>
Any thoughts for us ?
Regards--
Subrata
> Regards--
> Subrata
>
> > * Reserved space for online fsck and the ability to add storage so that a
> > * background extent allocation check can proceed
> > * Additional ioctls to set per-inode attributes (nodatacow, nodatasum, etc)
> >
> > So I think all of those are still true. Things that I know are being worked on
> > are
> >
> > * async block group cacheing - me
> > * locking changes - Chris
> > * backref stuff - Yan
> >
> > Som other things off the top of my head are
> >
> > * a better way to cache block groups in general, for this I was thinking of a
> > bitmap or something like that per block group of free space
> > * space balancing. this will likely need to wait on proper ENOSPC handling
> > * grub support :)
> >
> > Thats all that I can think of atm. Add things to the list if you think of them,
> > and hopefully we can update the wiki early next week. Thanks,
> >
> > Josef
> > --
> > To unsubscribe from this list: send the line "unsubscribe linux-btrfs" in
> > the body of a message to majordomo@vger.kernel.org
> > More majordomo info at http://vger.kernel.org/majordomo-info.html
>
>
> ------------------------------------------------------------------------------
> This SF.net email is sponsored by:
> High Quality Requirements in a Collaborative Environment.
> Download a free trial of Rational Requirements Composer Now!
> http://p.sf.net/sfu/www-ibm-com
> _______________________________________________
> Ltp-list mailing list
> Ltp-list@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/ltp-list
prev parent reply other threads:[~2009-04-13 13:14 UTC|newest]
Thread overview: 8+ messages / expand[flat|nested] mbox.gz Atom feed top
2009-04-09 16:24 Btrfs TODO Josef Bacik
2009-04-09 16:34 ` Ray Van Dolson
2009-04-09 18:30 ` Jeff Mahoney
2009-04-09 18:35 ` Josef Bacik
2009-04-09 20:23 ` jim owens
2009-04-10 5:53 ` Hisashi Hifumi
2009-04-10 6:42 ` Subrata Modak
2009-04-13 13:14 ` Subrata Modak [this message]
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=1239628449.16922.18.camel@subratamodak.linux.ibm.com \
--to=subrata@linux.vnet.ibm.com \
--cc=josef@redhat.com \
--cc=linux-btrfs@vger.kernel.org \
--cc=ltp-list@lists.sf.net \
/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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox