Li Zefan, Tue, 12 Jul 2011 16:44:31 +0800:
I've been monitoring the lists for a while now but didn't see this
problem mentioned in particular: I've got a fairly standard desktop
system at home, 700gb WD drive, nothing special, with 2 btrfs
filesystems and some snapshots. The sy
Excerpts from Chris Mason's message of 2011-07-25 21:28:30 -0400:
> Excerpts from Chris Mason's message of 2011-07-25 14:34:49 -0400:
> > Hi everyone,
> >
> > I've updated the integration-test branch to use this code instead. It
> > is a shiny new reader/writer lock built around rw spinlocks. I'
We have been using bytes_reserved for metadata reservations, which is wrong
since we use that to keep track of outstanding reservations from the allocator.
This resulted in us doing a lot of silly things to make sure we don't allocate a
bunch of metadata chunks since we never had a real view of how
This just switches us back to the old way of doing csum calculations. It is
broken, but less broken than what I fixed it with, so revert it and I'll come up
with something more correct for later. Thanks,
Signed-off-by: Josef Bacik
---
fs/btrfs/extent-tree.c | 20 +++-
1 files
On Wed, 27 Jul 2011 01:46:48 +0600
Roman Mamedov wrote:
> "WARNING: at fs/btrfs/inode.c:6775 btrfs_destroy_inode",
>
> void btrfs_destroy_inode(struct inode *inode)
> {
> struct btrfs_ordered_extent *ordered;
> struct btrfs_root *root = BTRFS_I(inode)->root;
>
> 6775->WARN_O
On Wed, 27 Jul 2011 01:37:56 +0600
Roman Mamedov wrote:
> On Wed, 27 Jul 2011 01:02:32 +0600
> Roman Mamedov wrote:
>
> > > - Can this filesystem (nodesize 16384 leafsize 16384 sectorsize 16384) be
> > > mounted on an
> > > x86 system with page size of 4K at all, if I move the disk there
>
On Wed, 27 Jul 2011 01:02:32 +0600
Roman Mamedov wrote:
> > - Can this filesystem (nodesize 16384 leafsize 16384 sectorsize 16384) be
> > mounted on an
> > x86 system with page size of 4K at all, if I move the disk there (didn't
> > try that yet)?
Just tried on an amd64 system, and 1) it mou
On Mon, 27 Jun 2011 01:00:18 +0600
Roman Mamedov wrote:
> I am having some trouble with btrfs on the MIPS (Little Endian) architecture.
>
> Linux hoshi 2.6.39-libre-lemote-rm1 #1 Sun May 29 17:48:16 YEKST 2011 mips64
> GNU/Linux
>
> btrfs-tools0.19+20101101-1
>
> First of all,
Hello,
I'm going to be going through our ENOSPC handling to make it simpler and
fixing the various performance problems and too early problems we have
been seeing. I'm going to target these for 3.2, but I'm going to post
them as I churn them out so people can review them and test them.
Please res
On 26.07.2011 12:12, Jan Schubert wrote:
> On 07/26/2011 12:04 PM, Jan Schmidt wrote:
>> On 25.07.2011 17:58, Jan Schubert wrote:
>>> btrfs: unable to fixup at 182245531648
>>> btrfs: unable to fixup at 182245535744
>>> btrfs: unable to fixup at 182245539840
>> This is due to rate limitation of p
On 25/07/11 23:10, Mark Fasheh wrote:
> On Fri, Jul 22, 2011 at 09:45:19AM +0900, Tsutomu Itoh wrote:
>> (2011/07/22 4:48), Mark Fasheh wrote:
>>> In addition to properly handling allocation failure from btrfs_alloc_path, I
>>> also fixed up the kzalloc error handling code immediately below it.
>>>
Filesystem is almost empty:
/dev/mapper/vg_md1-btrfs
155G 2,1G 152G 2% /mnt/btrfs
File system is made using command
mkfs.btrfs /dev/mapper/vg_md1-btrfs
If you can't reproduce this I can try to compile kernel
using debug stuff
-Markus
2011/7/26 cwillu :
> On Tue, J
On Tue, Jul 26, 2011 at 1:51 AM, Markus Suvanto
wrote:
> This is what I get if I use command:
> bcp file file_copy
> I can reproduce this every time when using bcp command.
>
> Filesystem is under lvm:
> /dev/mapper/vg_md1-btrfs on /mnt/btrfs type btrfs (rw,noatime,subvol=.)
>
> This filesystem i
This is what I get if I use command:
bcp file file_copy
I can reproduce this every time when using bcp command.
Filesystem is under lvm:
/dev/mapper/vg_md1-btrfs on /mnt/btrfs type btrfs (rw,noatime,subvol=.)
This filesystem is created using linux-3.0 and
mkfs.btrfs, part of Btrfs v0.19-1-g4f89b
14 matches
Mail list logo
