Signed-off-by: Cong Wang
---
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 |8
fs/btr
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/
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 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 e
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 debu
On Wed, Feb 8, 2012 at 8:14 PM, Liu Bo wrote:
> On 02/09/2012 05:01 AM, Mitch Harder wrote:
>> On Wed, Jan 18, 2012 at 10:13 AM, Mitch Harder
>> wrote:
>>> I have a Btrfs partition that is reliably reproducing premature ENOSPC
>>> when restoring the disk from a tar file, but it is only happening
On Thu, Feb 9, 2012 at 12:20 PM, Roman Mamedov wrote:
> On Thu, 09 Feb 2012 18:42:32 +0100
> "Norbert Scheibner" 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
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] do
On Thu, 09 Feb 2012 18:42:32 +0100
"Norbert Scheibner" 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 many aspects,
On Thu, Feb 9, 2012 at 11:42 AM, Norbert Scheibner 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 then d
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 full-ba
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
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
> @@ -765
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.
R
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
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 de
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
17 matches
Mail list logo
