On 07/15/2011 05:50 PM, Christoph Hellwig wrote:
On Fri, Jul 15, 2011 at 05:26:38PM -0400, Josef Bacik wrote:
Everybody else does this, we need to do it too. If we're syncing, we need to
tag the pages we're going to write for writeback so we don't end up writing the
same stuff over and over aga
On Sat, Jul 16, 2011 at 3:51 AM, mck wrote:
> My laptop btrfs partition has become corrupt after a power+battery
> outage.
>
> # btrfs-show
> Label: none uuid: e7b37e5d-c704-4ca8-ae7e-f22dd063e165
> Total devices 1 FS bytes used 116.33GB
> devid 1 size 226.66GB used 226.66GB path
My laptop btrfs partition has become corrupt after a power+battery
outage.
# btrfs-show
Label: none uuid: e7b37e5d-c704-4ca8-ae7e-f22dd063e165
Total devices 1 FS bytes used 116.33GB
devid1 size 226.66GB used 226.66GB path /dev/sda4
I typically mount w/
-o subvol=xyz,
On Fri, Jul 15, 2011 at 05:26:38PM -0400, Josef Bacik wrote:
> Everybody else does this, we need to do it too. If we're syncing, we need to
> tag the pages we're going to write for writeback so we don't end up writing
> the
> same stuff over and over again if somebody is constantly redirtying our
Everybody else does this, we need to do it too. If we're syncing, we need to
tag the pages we're going to write for writeback so we don't end up writing the
same stuff over and over again if somebody is constantly redirtying our file.
This will keep us from having latencies with heavy sync workloa
Currently we reserve enough space to COW an entirely full btree for every extent
we have reserved for an inode. This _sucks_, because you only need to COW once,
and then everybody else is ok. Unfortunately we don't know we'll all be able to
get into the same transaction so that's what we have had
On 07/15/2011 06:01 PM, da...@lang.hm wrote:
On Fri, 15 Jul 2011, Ric Wheeler wrote:
On 07/15/2011 05:23 PM, da...@lang.hm wrote:
On Fri, 15 Jul 2011, Chris Mason wrote:
Excerpts from Ric Wheeler's message of 2011-07-15 08:58:04 -0400:
On 07/15/2011 12:34 PM, Chris Mason wrote:
By bubble
On Fri, 15 Jul 2011, Ric Wheeler wrote:
On 07/15/2011 05:23 PM, da...@lang.hm wrote:
On Fri, 15 Jul 2011, Chris Mason wrote:
Excerpts from Ric Wheeler's message of 2011-07-15 08:58:04 -0400:
On 07/15/2011 12:34 PM, Chris Mason wrote:
By bubble up I mean that if you have multiple layers cap
On 07/15/2011 05:23 PM, da...@lang.hm wrote:
On Fri, 15 Jul 2011, Chris Mason wrote:
Excerpts from Ric Wheeler's message of 2011-07-15 08:58:04 -0400:
On 07/15/2011 12:34 PM, Chris Mason wrote:
By bubble up I mean that if you have multiple layers capable of doing
retries, the lowest levels w
On Fri, 15 Jul 2011, Chris Mason wrote:
Excerpts from Ric Wheeler's message of 2011-07-15 08:58:04 -0400:
On 07/15/2011 12:34 PM, Chris Mason wrote:
By bubble up I mean that if you have multiple layers capable of doing
retries, the lowest levels would retry first. Basically by the time we
ge
On Fri, 15 Jul 2011, NeilBrown wrote:
On Thu, 14 Jul 2011 21:58:46 -0700 (PDT) da...@lang.hm wrote:
On Thu, 14 Jul 2011, Chris Mason wrote:
Excerpts from Ric Wheeler's message of 2011-07-14 02:57:54 -0400:
On 07/14/2011 07:38 AM, NeilBrown wrote:
On Thu, 14 Jul 2011 07:02:22 +0100 Ric Whee
Kill the check to see if we have 512mb of reserved space in delalloc and
shrink_delalloc if we do. This causes unexpected latencies and we have other
logic to see if we need to throttle. Thanks,
Signed-off-by: Josef Bacik
---
fs/btrfs/extent-tree.c |3 ---
1 files changed, 0 insertions(+),
So I had this brilliant idea to use atomic counters for outstanding and reserved
extents, but this turned out to be a bad idea. Consider this where we have 1
outstanding extent and 1 reserved extent
ReserverReleaser
atomic_de
Am Freitag, den 15.07.2011, 10:24 -0400 schrieb Chris Mason:
> Excerpts from Hugo Mills's message of 2011-07-15 10:07:24 -0400:
> > On Fri, Jul 15, 2011 at 10:00:35AM -0400, Chris Mason wrote:
> > > Excerpts from Ric Wheeler's message of 2011-07-15 09:31:37 -0400:
> > > > On 07/15/2011 02:20 PM, Ch
Excerpts from Hugo Mills's message of 2011-07-15 10:54:36 -0400:
> On Fri, Jul 15, 2011 at 10:24:25AM -0400, Chris Mason wrote:
> > Excerpts from Hugo Mills's message of 2011-07-15 10:07:24 -0400:
> > > On Fri, Jul 15, 2011 at 10:00:35AM -0400, Chris Mason wrote:
> > > > Excerpts from Ric Wheeler's
On Fri, Jul 15, 2011 at 10:24:25AM -0400, Chris Mason wrote:
> Excerpts from Hugo Mills's message of 2011-07-15 10:07:24 -0400:
> > On Fri, Jul 15, 2011 at 10:00:35AM -0400, Chris Mason wrote:
> > > Excerpts from Ric Wheeler's message of 2011-07-15 09:31:37 -0400:
> > > > On 07/15/2011 02:20 PM, Ch
Excerpts from Hugo Mills's message of 2011-07-15 10:07:24 -0400:
> On Fri, Jul 15, 2011 at 10:00:35AM -0400, Chris Mason wrote:
> > Excerpts from Ric Wheeler's message of 2011-07-15 09:31:37 -0400:
> > > On 07/15/2011 02:20 PM, Chris Mason wrote:
> > > > Excerpts from Ric Wheeler's message of 2011-
On Fri, Jul 15, 2011 at 10:00:35AM -0400, Chris Mason wrote:
> Excerpts from Ric Wheeler's message of 2011-07-15 09:31:37 -0400:
> > On 07/15/2011 02:20 PM, Chris Mason wrote:
> > > Excerpts from Ric Wheeler's message of 2011-07-15 08:58:04 -0400:
> > >> On 07/15/2011 12:34 PM, Chris Mason wrote:
>
Excerpts from Ric Wheeler's message of 2011-07-15 09:31:37 -0400:
> On 07/15/2011 02:20 PM, Chris Mason wrote:
> > Excerpts from Ric Wheeler's message of 2011-07-15 08:58:04 -0400:
> >> On 07/15/2011 12:34 PM, Chris Mason wrote:
> > [ triggering IO retries on failed crc or other checks ]
> >
> >>>
On Fri, Jul 15, 2011 at 8:58 AM, Ric Wheeler wrote:
> On 07/15/2011 12:34 PM, Chris Mason wrote:
>>
>> Excerpts from NeilBrown's message of 2011-07-15 02:33:54 -0400:
>>>
>>> On Thu, 14 Jul 2011 21:58:46 -0700 (PDT) da...@lang.hm wrote:
>>>
On Thu, 14 Jul 2011, Chris Mason wrote:
> E
On 07/14/2011 10:56 PM, liubo wrote:
> On 07/15/2011 01:26 AM, Josef Bacik wrote:
>> Hit this nice little deadlock. What happens is this
>>
>> __btrfs_end_transaction with throttle set, --use_count so it equals 0
>> btrfs_commit_transaction
>>
>> btrfs_end_transaction --use_count so now
On 07/15/2011 02:20 PM, Chris Mason wrote:
Excerpts from Ric Wheeler's message of 2011-07-15 08:58:04 -0400:
On 07/15/2011 12:34 PM, Chris Mason wrote:
[ triggering IO retries on failed crc or other checks ]
But, maybe the whole btrfs model is backwards for a generic layer.
Instead of sending
Excerpts from Ric Wheeler's message of 2011-07-15 08:58:04 -0400:
> On 07/15/2011 12:34 PM, Chris Mason wrote:
[ triggering IO retries on failed crc or other checks ]
> >
> > But, maybe the whole btrfs model is backwards for a generic layer.
> > Instead of sending down ios and testing when they c
On 07/15/2011 12:34 PM, Chris Mason wrote:
Excerpts from NeilBrown's message of 2011-07-15 02:33:54 -0400:
On Thu, 14 Jul 2011 21:58:46 -0700 (PDT) da...@lang.hm wrote:
On Thu, 14 Jul 2011, Chris Mason wrote:
Excerpts from Ric Wheeler's message of 2011-07-14 02:57:54 -0400:
On 07/14/2011 07
Excerpts from NeilBrown's message of 2011-07-15 02:33:54 -0400:
> On Thu, 14 Jul 2011 21:58:46 -0700 (PDT) da...@lang.hm wrote:
>
> > On Thu, 14 Jul 2011, Chris Mason wrote:
> >
> > > Excerpts from Ric Wheeler's message of 2011-07-14 02:57:54 -0400:
> > >> On 07/14/2011 07:38 AM, NeilBrown wrote:
When we balanced the chunks across the devices, BUG_ON() in
__finish_chunk_alloc() was triggered.
[ cut here ]
kernel BUG at fs/btrfs/volumes.c:2568!
[SNIP]
Call Trace:
[] btrfs_alloc_chunk+0x8e/0xa0 [btrfs]
[] do_chunk_alloc+0x330/0x3a0 [btrfs]
[] btrfs_reserve_extent+0
26 matches
Mail list logo