On Fri, Aug 07, 2009 at 08:56:52AM -0500, Steven Pratt wrote:
> Chris Mason wrote:
> >On Tue, Jul 28, 2009 at 04:10:41PM -0500, Steven Pratt wrote:
> >>>Hi Steve,
> >>>
> >>>I think I'm going to start tuning something other than the
> >>>random-writes, there is definitely low hanging fruit in the l
Hello everyone,
Linus, please pull these from the master branch of:
git://git.kernel.org/pub/scm/linux/kernel/git/mason/btrfs-unstable.git
These are relatively small bug fixes, including two fixes for
tree-log recovery on mount (one oops and one infinite loop).
Bartlomiej Zolnierkiewicz (1) co
Seems like this could be useful for searching for free space chunks as well.
If you're looking for a chunk of free space aligned on a chunksize boundary
(which btrfs prefers if I'm not mistaken), then searching this tree would be
much faster than searching a bitmap, particularly when what you'r
On Fri, 2009-08-07 at 11:43 +0200, Roy Sigurd Karlsbakk wrote:
> This is great. How does the current code handle corruption on a drive,
> or two drives with RAID-6 in a stripe? Is the checksumming done per
> drive or for the whole stripe?
http://git.infradead.org/users/dwmw2/btrfs-raid56.git
--
Chris Mason wrote:
On Tue, Jul 28, 2009 at 04:10:41PM -0500, Steven Pratt wrote:
Hi Steve,
I think I'm going to start tuning something other than the
random-writes, there is definitely low hanging fruit in the large file
creates workload ;) Thanks again for posting all of these.
Sur
debian developer wrote:
HI,
Do you have any benchmarks against non-raid common workloads?
Like say a desktop user? It would be great to compare against ext3,
ext4, xfs etc.,
Yes, have had a little trouble with that box recently, but plenty of
results based on the 2.6.29 kernels here:
http:
On Thu, Jul 23, 2009 at 06:50:53PM +0200, Tomasz Chmielewski wrote:
> Tomasz Torcz wrote:
>> On Wed, Jul 22, 2009 at 10:40:31AM -0400, Chris Mason wrote:
>>> On Wed, Jul 22, 2009 at 01:27:06PM +0200, Tomasz Torcz wrote:
Hi,
I tried to export file from btrfs volume using iSCSI targe
On Fri, Aug 07, 2009 at 05:07:32PM +0800, Yan Zheng wrote:
> On 08/07/2009 03:19 PM, Jens Axboe wrote:
> > On Fri, Aug 07 2009, Yan Zheng wrote:
> >> On 08/07/2009 02:50 PM, Jens Axboe wrote:
> >>> On Fri, Aug 07 2009, Yan Zheng wrote:
> invalidate_inode_pages2_range may return -EBUSY occasion
Hi!
I spotted the recent Btrfs changes related to free space
tracking and I am interested whether one datastracture I
came up with might be of any help. It is named a "binmap",
basically a hybrid of a bitmap and a binary tree. It is
useful for holding well-aggregatable bitmaps with long
extents o
Hi
This is great. How does the current code handle corruption on a drive,
or two drives with RAID-6 in a stripe? Is the checksumming done per
drive or for the whole stripe?
roy
On 6. aug.. 2009, at 12.17, David Woodhouse wrote:
If we've abandoned the idea of putting the number of redunda
On 08/07/2009 03:19 PM, Jens Axboe wrote:
> On Fri, Aug 07 2009, Yan Zheng wrote:
>> On 08/07/2009 02:50 PM, Jens Axboe wrote:
>>> On Fri, Aug 07 2009, Yan Zheng wrote:
invalidate_inode_pages2_range may return -EBUSY occasionally
which results Oops. This patch fixes the issue by moving
>>
HI,
Do you have any benchmarks against non-raid common workloads?
Like say a desktop user? It would be great to compare against ext3,
ext4, xfs etc.,
Thanks,
On Thu, Aug 6, 2009 at 2:05 AM, Chris Mason wrote:
> On Tue, Jul 28, 2009 at 04:10:41PM -0500, Steven Pratt wrote:
>> >
>> >Hi Steve,
>> >
On Fri, Aug 07 2009, Yan Zheng wrote:
> On 08/07/2009 02:50 PM, Jens Axboe wrote:
> > On Fri, Aug 07 2009, Yan Zheng wrote:
> >> invalidate_inode_pages2_range may return -EBUSY occasionally
> >> which results Oops. This patch fixes the issue by moving
> >> invalidate_inode_pages2_range into a loop
On 08/07/2009 02:50 PM, Jens Axboe wrote:
> On Fri, Aug 07 2009, Yan Zheng wrote:
>> invalidate_inode_pages2_range may return -EBUSY occasionally
>> which results Oops. This patch fixes the issue by moving
>> invalidate_inode_pages2_range into a loop and keeping calling
>> it until the return value
14 matches
Mail list logo
