On 02/06/2012 04:37 AM, Lutz Euler wrote:
... maybe even the block group cache is nonfunctional then?
I am using a btrfs file system, mirrored data and metadata on two SSDs,
and recently tried for the first time to run fstrim on it. fstrim
unexpectedly said 0 bytes were trimmed. strace -T
A user reported a bug of btrfs's trim, that is we will trim 0 bytes
after a device delete.
The reproducer:
$ mkfs.btrfs disk1
$ mkfs.btrfs disk2
$ mount disk1 /mnt
$ fstrim -v /mnt
$ btrfs device add disk2 /mnt
$ btrfs device del disk1 /mnt
$ fstrim -v /mnt
This is because after we delete the
On Mon, Feb 06, 2012 at 01:52:15PM +, Al Viro wrote:
On Mon, Feb 06, 2012 at 07:18:24AM -0500, Christoph Hellwig wrote:
On Mon, Feb 06, 2012 at 12:53:21PM +0100, David Sterba wrote:
On Sun, Feb 05, 2012 at 12:30:42PM +0200, Nikos Voutsinas wrote:
It's quite old, but what was this
Because scrub enumerates the dev extent tree to find the chunks to scrub,
it currently finds each DUP chunk twice and also scrubs it twice. This
patch makes sure that scrub_chunk only checks that part of the chunk the
dev extent has been found for. This only changes the behaviour for DUP
chunks.
Hi Liu,
thanks for looking into this!
You wrote:
Would you please test the following patch on your box?
thanks,
liubo
diff --git a/fs/btrfs/extent-tree.c b/fs/btrfs/extent-tree.c
index 77ea23c..b6e2c92 100644
--- a/fs/btrfs/extent-tree.c
+++ b/fs/btrfs/extent-tree.c
@@ -7653,9
On Thu, Jan 26, 2012 at 04:53:43PM +0800, Anand Jain wrote:
Further I hope the new contents created on btrfs.ipv5.de
will be merged with btrfs.wiki.kernel.org when the latter
is ready.
Sure, that's the plan.
david
--
To unsubscribe from this list: send the line unsubscribe linux-btrfs in
the
Glück Auf!
I use now kernel 3.2. The filesystem was originally created under 2.6.39 on 1
whole hdd, mounted with noatime,nodiratime,inode_cache. I use it for backups:
rsync the whole system to a subvolume, snapshot it and then delete some
tempfiles in the snapshot, which are 90% of the
On Thu, Feb 9, 2012 at 11:42 AM, Norbert Scheibner s...@gmx.net wrote:
Glück Auf!
I use now kernel 3.2. The filesystem was originally created under 2.6.39 on 1
whole hdd, mounted with noatime,nodiratime,inode_cache. I use it for
backups: rsync the whole system to a subvolume, snapshot it and
On Thu, 09 Feb 2012 18:42:32 +0100
Norbert Scheibner s...@gmx.net wrote:
So the used space of subvolume I deleted, was not freed.
AFAIK the only reliable way currently to ensure the space after a subvolume
deletion is freed, is to remount the FS.
In my opinion this is very inconvenient in
On Thu, 9 Feb 2012 12:11:19 -0600 Chester wrote:
A similar thing has happened to me recently. The snapshot deletion
happens asynchronously and should continue after a reboot (in my
case). If you boot up your system and leave it idle, take a look at
iotop. You might see a [btrfs-cleaner] doing
On Thu, Feb 9, 2012 at 12:20 PM, Roman Mamedov r...@romanrm.ru wrote:
On Thu, 09 Feb 2012 18:42:32 +0100
Norbert Scheibner s...@gmx.net wrote:
So the used space of subvolume I deleted, was not freed.
AFAIK the only reliable way currently to ensure the space after a subvolume
deletion is
On Wed, Feb 8, 2012 at 8:14 PM, Liu Bo liubo2...@cn.fujitsu.com wrote:
On 02/09/2012 05:01 AM, Mitch Harder wrote:
On Wed, Jan 18, 2012 at 10:13 AM, Mitch Harder
mitch.har...@sabayonlinux.org wrote:
I have a Btrfs partition that is reliably reproducing premature ENOSPC
when restoring the disk
This patch isn't intended for inclusion in the kernel, but is provided
to facilitate ENOSPC debugging in a framework that will have no
impact on Btrfs unless compiled conditionally.
Debugging printk statements are wrapped in #ifdef macros
to allow btrfs to be built in its original form unless
On 09/02/12 01:42, Liu Bo wrote:
On 02/09/2012 03:24 AM, Martin wrote:
[ No problem for 4kByte sector HDDs. However, for SSDs... ]
However for SSDs...
I'm using for example a 60GByte SSD that has:
8kB page size;
16kB logical to physical mapping chunk size;
2MB erase block
On Thu, Feb 09, 2012 at 06:54:42PM -0600, Chester wrote:
Output for btrfs-debug-tree for that specific block in dmesg
And available here ( http://pastebin.com/AgdvS5JM ) in case the lines
wrap and look ugly
Ok, good news. This bad block is in the extent allocation tree, which
means it is
On 02/09/2012 11:50 PM, Lutz Euler wrote:
Hi Liu,
thanks for looking into this!
You wrote:
Would you please test the following patch on your box?
thanks,
liubo
diff --git a/fs/btrfs/extent-tree.c b/fs/btrfs/extent-tree.c
index 77ea23c..b6e2c92 100644
--- a/fs/btrfs/extent-tree.c
Signed-off-by: Cong Wang amw...@redhat.com
---
fs/btrfs/compression.c | 12 ++--
fs/btrfs/extent_io.c | 16
fs/btrfs/file-item.c |4 ++--
fs/btrfs/inode.c | 26 +-
fs/btrfs/lzo.c |4 ++--
fs/btrfs/scrub.c |
17 matches
Mail list logo