The 'used' output of df on a btrfs system does not take metadata into
account. So the disk is really full. This is what my yesterdays path
is intended to fix - can you try it out?
On Wed, Feb 24, 2010 at 5:27 AM, Boyd Waters waters.b...@gmail.com wrote:
I believe there is a kerneloops associated
On Wed, Feb 24, 2010 at 03:12:05PM +0800, Shaohua Li wrote:
I got below oops when doing file write with mount option max_extent=1M
It appears the accouting is already done in set/clear/split/merge hooks and
I don't see reason why we need do accouting in __btrfs_remove_ordered_extent
again.
On Wed, Feb 24, 2010 at 03:12:05PM +0800, Shaohua Li wrote:
I got below oops when doing file write with mount option max_extent=1M
It appears the accouting is already done in set/clear/split/merge hooks and
I don't see reason why we need do accouting in __btrfs_remove_ordered_extent
again.
On Wed, Feb 24, 2010 at 03:12:05PM +0800, Shaohua Li wrote:
I got below oops when doing file write with mount option max_extent=1M
It appears the accouting is already done in set/clear/split/merge hooks and
I don't see reason why we need do accouting in __btrfs_remove_ordered_extent
again.
On Wednesday 24 February 2010, planetf1 wrote:
Hi,
Hi
Let me know if this is the wrong place to ask...
I'm using Fedora 12 x86_64, mostly with the newer 21.6.32 kernel, and
have a single btrfs filesystem within a 120Gb partition.
I'd like to extend the space btrfs can use. One
Thanks for the suggestions, everyone!
I copied the data from the 2TB btrfs disk to an identical disk (same
make and model) formatted with ext4:
/dev/sdi2 1.9T 1.7T 197G 90% /media/onlyhope
/dev/sdg1 1.8T 1.7T 71G 96% /mnt/newhope
The metadata overhead for btrfs is
I was wondering if there is a newer BTRFS version floating around
somewhere. The version tag on the one I got from git is Btrfs
v2.6.27-rc7-59199-g3f6fae9, which seems kinda old, even though the
kernel is 2.6.32. Thanks, and sorry for the newbie question, but the
git unstable is the only place i
On Mon, Feb 22, 2010 at 07:47:40PM +0100, Goffredo Baroncelli wrote:
On Monday 22 February 2010, Mike Fedyk wrote:
On Sun, Feb 21, 2010 at 8:40 AM, Goffredo Baroncelli kreij...@gmail.com
wrote:
filesystem resize [+/-]size[gkm]|max filesystem
-filesystem resize [+/-]size[gkm]|max
On Tue, Feb 23, 2010 at 08:30:56AM +, Alex Elsayed wrote:
Alex Elsayed eternaleye at gmail.com writes:
Chris Mason chris.mason at oracle.com writes:
I think the btrfsck output is missing. It sounds like we'll survive if
we just skip this part of the log replay. I'll cook a
On Wed, Feb 24, 2010 at 3:35 PM, Chris Mason chris.ma...@oracle.com wrote:
On Mon, Feb 22, 2010 at 07:47:40PM +0100, Goffredo Baroncelli wrote:
On Monday 22 February 2010, Mike Fedyk wrote:
On Sun, Feb 21, 2010 at 8:40 AM, Goffredo Baroncelli kreij...@gmail.com
wrote:
filesystem
Dear btrfs developers,
please excuse my seemingly non-sensical request at this time.. i in no
way have any knowledge about the inner workings of the windows
filesystem driver interface - but i think i do not have to explain why
it would be highly beneficial for a great number of people if a
The patch is here: http://patchwork.kernel.org/patch/81547/ , it's for kernel.
But I have just seen weird behaviour with my btrfs, I'm not sure
whether it's my patch or the new changes I have pulled from git - I'd
recommend you wait with trying out this patch until someone diagnoses
what failed
12 matches
Mail list logo
