Hello list,
I've been using btrfs for nearly 6 months now, on three machines, with
no problems but for _one_ filesystem on one machine. The problem is
the message in $subject.
For this particular filesystem, which contains qemu-kvm disk images in
raw mode with caching mode set to "writeback", the
This started appearing for me on v2.6.36-rc5-49-gc79bd89; it did not
happen on v2.6.36-rc5-33-g1ce1e41, probably because it does not have
commit 692ebd17c2905313fff3c504c249c6a0faad16ec which introduces the
warning.
[...]
device fsid 44d595920ddedfa-3ece6b56e80f689e devid 1 transid 22342
/dev
You can patch btrfs for experimental hot relocation.
Ben Chociej posted this: http://article.gmane.org/gmane.linux.kernel/1022603
--
Anish Tondwalkar
On Wed, Sep 22, 2010 at 7:04 PM, Bostjan Skufca wrote:
> Anyone?
>
> On 18 September 2010 01:33, Bostjan Skufca wrote:
>> Hi all!
>>
>> I was loo
Anyone?
On 18 September 2010 01:33, Bostjan Skufca wrote:
> Hi all!
>
> I was looking into some custom fileserver options and noticed two
> facts about ZFS - support for L2ARC (albeit not persistant across
> reboots, which is a downer) and OpenSolaris being a dead meat. Then I
> found out that so
On Wed, Sep 22, 2010 at 02:04:57PM +, Lubos Kolouch wrote:
> Chris Mason, Mon, 20 Sep 2010 08:13:07 -0400:
>
> > On Mon, Sep 20, 2010 at 12:10:08PM +, Lubos Kolouch wrote:
> >> On Mon, 20 Sep 2010 07:30:57 -0400, Chris Mason wrote:
> >>
> >> > On Mon, Sep 20, 2010 at 11:00:08AM +, Lub
Is there currently a way to view and manipulate the chunks? If I
understand things correctly, a new fs has a few chunks:
1) System chunk. Contains tree of trees, device tree, chunk tree.
2) Metadata chunk. Contains the directory tree for the default subvol,
and any additional subvols/snapshot
This is a simple bit, just dump the free space cache out to our preallocated
inode when we're writing out dirty block groups. There are a bunch of changes
in inode.c in order to account for special cases. Mostly when we're doing the
writeout we're holding trans_mutex, so we need to use the nolock
V1->V2
- This includes my previous fix for the Incompat flags that I posted earlier
- Fix kunmap() to use the page and not the vaddr, I messed this up when going
from kmap_atomic to kmap
This patch series introduces the ability for btrfs to store the free space cache
ondisk to make the caching of
This patch actually loads the free space cache if it exists. The only thing
that really changes here is that we need to cache the block group if we're going
to remove an extent from it. Previously we did not do this since the caching
kthread would pick it up. With the on disk cache we don't have
In order to save free space cache, we need an inode to hold the data, and we
need a special item to point at the right inode for the right block group. So
first, create a special item that will point to the right inode, and the number
of extent entries we will have and the number of bitmaps we wil
Chris Mason, Mon, 20 Sep 2010 08:13:07 -0400:
> On Mon, Sep 20, 2010 at 12:10:08PM +, Lubos Kolouch wrote:
>> On Mon, 20 Sep 2010 07:30:57 -0400, Chris Mason wrote:
>>
>> > On Mon, Sep 20, 2010 at 11:00:08AM +, Lubos Kolouch wrote:
>> >> No, not stable!
>> >>
>> >> Again, after powerloss
On Fri, Sep 17, 2010 at 10:45:38AM +0800, Shaohua Li wrote:
> Chris,
> we are seeing kernel warning from time to time when doing btrfs test.
> That issue is hard to trigger, but it sometimes pop up. we saw this in
> both fio and ffsb test in several kernel version. Below is an example.
> do you hav
On 22 September 2010 01:02, Chris Mason wrote:
> On Tue, Sep 21, 2010 at 12:27:03AM -0400, Dave Cundiff wrote:
>> On Mon, Sep 20, 2010 at 9:19 PM, K. Richard Pixley wrote:
>> > Do you have any kernel processes running constantly? Any taking near 100%
>> > of a CPU?
>> >
>> > --rich
>> >
>>
>> N
13 matches
Mail list logo
