On Mon, Feb 04, 2013 at 11:08:01AM +0200, Moshe wrote:
> Hello,
>
> If I write large sequential file on snapshot, then create another
> snapshot, overwrite file with small amount of data and delete first
> snapshot, second snapshot has very large data extent and only small
> part of it is used.
>
On Tue, Feb 05, 2013 at 05:27:45PM +0200, Moshe Melnikov wrote:
>
> Is it possible in step 1) to create few smaller extents instead of 1
> gig data extent?
DIO or O_SYNC can help to create extents whose size is your 'bs=xxx',
but you know, this is not expected as fast as buffered write.
thanks,
On Tue, Feb 05, 2013 at 03:14:05PM -0800, Zach Brown wrote:
> > + struct btrfs_inode *b_inode = BTRFS_I(inode);
> > + struct btrfs_fs_info *fs_info = b_inode->root->fs_info;
> >
> > if (atomic_add_unless(&inode->i_count, -1, 1))
> > return;
> >
> > - delayed = kmalloc(size
In some testing that was being done the tester ran into the following:
--
/mnt/abo is a filesystem in Raid1-configuration having two disks: /dev/sdg2
and /dev/sdg3. When trying to remove one of the devices, you get this error
on the console:
# btrfs device delete /dev/sdg2 /mnt/abo
ERROR: er
Hi gang,
Eric and I went through the warnings that a Coverity scan raised against
the reasonably recent btrfs-progs that's in Fedora. We tried to tackle
the lowest hanging fruit: these are the most obvious and least risky
fixes.
We got up to 40 patches before running out of steam. I was going t
I have a btrfs volume spread over three 3TB disks, RAID1 data and metadata.
The machine is old and underpowered; a 32-bit Atom box with 2GB of RAM.
On it is a 1TB sparse file which is a dm-crypt volume containing an
ext4 filesystem. For the past few months, I've been writing very
slowly to the in
> + struct btrfs_inode *b_inode = BTRFS_I(inode);
> + struct btrfs_fs_info *fs_info = b_inode->root->fs_info;
>
> if (atomic_add_unless(&inode->i_count, -1, 1))
> return;
>
> - delayed = kmalloc(sizeof(*delayed), GFP_NOFS | __GFP_NOFAIL);
> - delayed->inode =
Following the lead from Jeff Mahoney's comment in the code:
/* JDM: If this is fs-wide, why can't we add a pointer to
* btrfs_inode instead and avoid the allocation? */
Remove the NOFAIL kmalloc in btrfs_add_delayed_iput(), and just
use a list head in the btrfs inode.
This does grow the btrfs i
On Tue, Feb 05, 2013 at 01:37:50PM -0700, Marguerite Su wrote:
> On Wed, Feb 6, 2013 at 3:35 AM, Josef Bacik wrote:
> > Eesh can you fpaste this, it got wrapped by your mailer and I can't read it.
> > Thanks,
>
> Hi, Josef,
>
> Of course, http://paste.opensuse.org/80508108
>
> I at first though
On Wed, Feb 6, 2013 at 3:35 AM, Josef Bacik wrote:
> Eesh can you fpaste this, it got wrapped by your mailer and I can't read it.
> Thanks,
Hi, Josef,
Of course, http://paste.opensuse.org/80508108
I at first thought pasting here may help archive. but Gmail sucks...sorry!
Marguerite
--
To unsub
On Tue, Feb 05, 2013 at 12:27:04PM -0700, Marguerite Su wrote:
> Hi, I got a kernel crash or something said this.
>
> I see it attach a dump, so it seems btrfs devs are the only group who
> can read it...
>
Eesh can you fpaste this, it got wrapped by your mailer and I can't read it.
Thanks,
Jos
On Tue, Feb 05, 2013 at 07:22:36AM -0700, Tomasz Torcz wrote:
> Hi,
>
> I believe XOR_BLOCKS must be selected, otherwise build fails with:
> ERROR: "xor_blocks" [fs/btrfs/btrfs.ko] undefined!
>
>
> diff --git a/fs/btrfs/Kconfig b/fs/btrfs/Kconfig
> index 4f5dc93..5f583c8 100644
> --- a/fs/btr
Is it possible in step 1) to create few smaller extents instead of 1 gig
data extent?
Moshe
-Original Message-
From: Josef Bacik
Sent: Tuesday, February 05, 2013 4:41 PM
To: Moshe
Cc: Josef Bacik ; linux-btrfs@vger.kernel.org
Subject: Re: btrfs wastes disk space after snapshot delet
On Tue, Feb 05, 2013 at 02:09:02AM -0700, Moshe wrote:
> Thanks for your reply Josef.
> I want to experiment with extents size, to see how it influence size of
> extent tree. Can you point me to code that I can change to limit size of
> data extents?
So it's not the size of the data extents, it
Hi,
I believe XOR_BLOCKS must be selected, otherwise build fails with:
ERROR: "xor_blocks" [fs/btrfs/btrfs.ko] undefined!
diff --git a/fs/btrfs/Kconfig b/fs/btrfs/Kconfig
index 4f5dc93..5f583c8 100644
--- a/fs/btrfs/Kconfig
+++ b/fs/btrfs/Kconfig
@@ -7,6 +7,7 @@ config BTRFS_FS
select
On 05/02/13 13:46, Roman Mamedov wrote:
On Tue, 05 Feb 2013 10:16:34 +
Tomasz Kusmierz wrote:
that I was using one of those fantastic pci 4 port ethernet cards and
printer was directly to it - after moving it and everything else to
switch all problem and issues have went away. AT the momen
On 05/02/13 12:49, Chris Mason wrote:
On Tue, Feb 05, 2013 at 03:16:34AM -0700, Tomasz Kusmierz wrote:
On 16/01/13 09:21, Bernd Schubert wrote:
On 01/16/2013 12:32 AM, Tom Kusmierz wrote:
p.s. bizzare that when I "fill" ext4 partition with test data everything
check's up OK (crc over all file
On Tue, Feb 05, 2013 at 01:55:17AM -0700, "Piotr Pawłow" wrote:
> > mounts before it panics, can you capture all the output and reply to this
> > email
> > with it? Thanks,
>
> I'm sorry, I could not keep it longer in that state. I used btrfs-image to
> create metadata image from both disks, then
On Tue, 05 Feb 2013 10:16:34 +
Tomasz Kusmierz wrote:
> that I was using one of those fantastic pci 4 port ethernet cards and
> printer was directly to it - after moving it and everything else to
> switch all problem and issues have went away. AT the moment I'm running
> server for 2 weeks
On Tue, Feb 05, 2013 at 03:16:34AM -0700, Tomasz Kusmierz wrote:
> On 16/01/13 09:21, Bernd Schubert wrote:
> > On 01/16/2013 12:32 AM, Tom Kusmierz wrote:
> >
> >> p.s. bizzare that when I "fill" ext4 partition with test data everything
> >> check's up OK (crc over all files), but with Chris tool
On 16/01/13 09:21, Bernd Schubert wrote:
On 01/16/2013 12:32 AM, Tom Kusmierz wrote:
p.s. bizzare that when I "fill" ext4 partition with test data everything
check's up OK (crc over all files), but with Chris tool it gets
corrupted - for both Adaptec crappy pcie controller and for mother board
On Fri, Feb 01, 2013 at 04:05:17PM -0500, Josef Bacik wrote:
> Dave sent me a panic where we were doing the orphan cleanup and panic'ed
> trying to release our reservation from the orphan block rsv. The reason for
> this is because our orphan block rsv had been free'd out from underneath us
> beca
Thanks for your reply Josef.
I want to experiment with extents size, to see how it influence size of
extent tree. Can you point me to code that I can change to limit size of
data extents?
Thanks,
Moshe Melnikov
-Original Message-
From: Josef Bacik
Sent: Monday, February 04, 2013 5:
> mounts before it panics, can you capture all the output and reply to this
> email
> with it? Thanks,
I'm sorry, I could not keep it longer in that state. I used btrfs-image to
create metadata image from both disks, then let it run without space
cache.
Unfortunately, when I run qemu with these
24 matches
Mail list logo