Hi Linus,
Please pull my for-linus branch:
git://git.kernel.org/pub/scm/linux/kernel/git/mason/linux-btrfs.git for-linus
We've had a busy two weeks of bug fixing. The biggest patches in here
are some long standing early-enospc problems (Josef) and a very old race
where compression and mmap comb
On Wed, Mar 27, 2013 at 07:03:49PM +1300, Mike Dilger wrote:
> I have been using it to make backups using rsync like this:
> 1) snapshot the previous backup subvolume
> 2) rsync into the new snapshot
> 3) If we are overwriting a previous backup "level", drop that previous
> subvolume and rename th
On Thu, Mar 21, 2013 at 11:56:37AM -0700, Ask Bjørn Hansen wrote:
> A few weeks ago I replaced a ZFS backup system with one backed by
> btrfs. A script loops over a bunch of hosts rsyncing them to each
> their own subvolume. After each rsync I snapshot the "host-specific"
> subvolume.
>
> The "di
Hi,
a few comments that reflect current implementation
On Tue, Mar 26, 2013 at 02:36:12PM -0500, Eric Sandeen wrote:
> +When mounting a btrfs filesystem, the following option are accepted.
> +Unless otherwise specified, all options default to off.
> +
> + alloc_start=
> + Debugging option to
On Fri, Mar 29, 2013 at 1:21 AM, Chris Murphy wrote:
> Chris Murphy wrote:
>> On Mar 29, 2013, at 12:04 AM, cwillu wrote:
>>
>>> commit 1a72afaa "btrfs-progs: mkfs support for extended inode refs"
>>> unconditionally enables extended irefs (which permits more than 4k
>>> links to the same inode).
Ah, now it makes sense!! Thanks!
On Fri, Mar 29, 2013 at 3:27 PM, Hugo Mills wrote:
> On Fri, Mar 29, 2013 at 03:18:03PM +0100, Harald Glatt wrote:
>> Sorry I forgot to post that,
>>
>> -> btrfs fi show
>> Label: none uuid: 2feccf06-5af8-4d8a-ad8d-a090cf4ef69a
>> Total devices 2 FS bytes use
On Fri, Mar 29, 2013 at 03:18:03PM +0100, Harald Glatt wrote:
> Sorry I forgot to post that,
>
> -> btrfs fi show
> Label: none uuid: 2feccf06-5af8-4d8a-ad8d-a090cf4ef69a
> Total devices 2 FS bytes used 16.54GB
> devid1 size 40.90GB used 14.04GB path /dev/sda7
> devid2 size 17.75GB used 1
Sorry I forgot to post that,
-> btrfs fi show
Label: none uuid: 2feccf06-5af8-4d8a-ad8d-a090cf4ef69a
Total devices 2 FS bytes used 16.54GB
devid1 size 40.90GB used 14.04GB path /dev/sda7
devid2 size 17.75GB used 14.03GB path /dev/sda6
The array is more of a for-fun and testing thing than
On Fri, Mar 29, 2013 at 07:58:40AM -0600, Harald Glatt wrote:
> Hi,
>
> I'm somewhat confused with who is right on what when it comes to
> showing disk usage and space free.
>
> I have a file system that I'm using for testing with a full linux
> installed as well as X and a desktop. I've created
A user reported a panic where we were panicing somewhere in
tree_backref_for_extent from scrub_print_warning. He only captured the trace
but looking at scrub_print_warning we drop the path right before we mess with
the extent buffer to print out a bunch of stuff, which isn't right. So fix this
by
Hi,
I'm somewhat confused with who is right on what when it comes to
showing disk usage and space free.
I have a file system that I'm using for testing with a full linux
installed as well as X and a desktop. I've created a good amount of
snapshots and I've also done a lot of changes to the system
On Fri, Mar 29, 2013 at 07:39:06AM -0600, Swâmi Petaramesh wrote:
> Le 29/03/2013 14:26, Josef Bacik a écrit :
> > after you've run sysrq+w and then reply with the URL it spits out. Thanks,
> I'm afraid I won't be able to do this this afternoon : I also need to
> work on my machine ;-) so for now
From: Wang Shilong
Just remove the unnecessary check and assignment.
Signed-off-by: Wang Shilong
---
fs/btrfs/backref.c | 3 +--
1 file changed, 1 insertion(+), 2 deletions(-)
diff --git a/fs/btrfs/backref.c b/fs/btrfs/backref.c
index 3ca413bb..e102b48 100644
--- a/fs/btrfs/backref.c
+++ b/fs
Le 29/03/2013 14:26, Josef Bacik a écrit :
> after you've run sysrq+w and then reply with the URL it spits out. Thanks,
I'm afraid I won't be able to do this this afternoon : I also need to
work on my machine ;-) so for now I will avoid to restart a scrub that
would possibly crash it once more...
Le 29/03/2013 14:12, Josef Bacik a écrit :
> Screenshots are welcome
This time I good a real nice kernel Ooops during scrub...
http://dl.free.fr/hjAdOH3mG
(use your email address or the list's one to fetch it)
--
Swâmi Petaramesh http://petaramesh.org PGP 9076E32E
Ne cherchez pas : Je ne suis
> Actually instead of netconsole we have an awesome service provided by Carey,
> you
> can just do
>
> nc cwillu.com 10101 < /dev/kmsg
... at a root prompt.
> after you've run sysrq+w and then reply with the URL it spits out. Thanks,
--
To unsubscribe from this list: send the line "unsubscribe
On Fri, Mar 29, 2013 at 07:06:33AM -0600, Swâmi Petaramesh wrote:
> Hi Josef,
>
> Le 29/03/2013 13:58, Josef Bacik a écrit :
> > So this is probably because of the extent tree corruption you had, it's just
> > cleaning things up and you should be fine once it finishes. Thanks,
>
> Er... It's on
Le 29/03/2013 14:12, Josef Bacik a écrit :
> Screenshots are welcome,
I posted one to http://dl.free.fr/jsRQ8JXZh (use your email address or
the list's one to fetch it)
It may or may not be very interesting, but that's all I got.
> I have no doubt scrub is fixing actual problems
Looks like it a
On Fri, Mar 29, 2013 at 07:06:33AM -0600, Swâmi Petaramesh wrote:
> Hi Josef,
>
> Le 29/03/2013 13:58, Josef Bacik a écrit :
> > So this is probably because of the extent tree corruption you had, it's just
> > cleaning things up and you should be fine once it finishes. Thanks,
>
> Er... It's on
On Fri, Mar 29, 2013 at 02:06:39PM +0100, Harald Glatt wrote:
> On that note, is btrfs doing automatic background scrubs of its own or
> do I have to use crontab to schedule scrubs?
If you want a full-disk scrub, you'll need to schedule it yourself
with cron (I run mine once a month). However,
On that note, is btrfs doing automatic background scrubs of its own or
do I have to use crontab to schedule scrubs?
Thanks!
On Fri, Mar 29, 2013 at 1:58 PM, Josef Bacik wrote:
> On Fri, Mar 29, 2013 at 03:50:15AM -0600, Swāmi Petaramesh wrote:
>> Hi there,
>>
>> I've started "btrfs scrub start /
Hi Josef,
Le 29/03/2013 13:58, Josef Bacik a écrit :
> So this is probably because of the extent tree corruption you had, it's just
> cleaning things up and you should be fine once it finishes. Thanks,
Er... It's on a different machine !
Current (at the time I write) status is :
# btrfs scrub
From: Wang Shilong
If btrfs_find_all_roots() fails, 'roots' has been freed or 'roots'
fails to allocate. we don't need to free it outside btrfs_find_all_roots()
again.Fix it.
Signed-off-by: Wang Shilong
---
fs/btrfs/backref.c | 1 -
1 file changed, 1 deletion(-)
diff --git a/fs/btrfs/backref.
On Fri, Mar 29, 2013 at 03:50:15AM -0600, Swâmi Petaramesh wrote:
> Hi there,
>
> I've started "btrfs scrub start /" on one of my machines (Kernel
> 3.8.0-15 Ubuntu AMD64), which typically "behaves well" so I wasn't
> suspected any disk issue.
>
> After having ran for only 165 seconds, "scrub sta
Quoting Alexandre Oliva (2013-03-29 05:56:06)
> On Mar 25, 2013, Chris Mason wrote:
>
> > This patch changes our compression code to call clear_page_dirty_for_io
> > before we compress, and then redirty the pages if the compression fails.
>
> > Alexandre, many thanks for tracking this down into
On Mar 25, 2013, Chris Mason wrote:
> This patch changes our compression code to call clear_page_dirty_for_io
> before we compress, and then redirty the pages if the compression fails.
> Alexandre, many thanks for tracking this down into a well defined use
> case.
Thanks for the patch, it's ru
Hi there,
I've started "btrfs scrub start /" on one of my machines (Kernel
3.8.0-15 Ubuntu AMD64), which typically "behaves well" so I wasn't
suspected any disk issue.
After having ran for only 165 seconds, "scrub status" shows it pretends
having found and corrected 22926 CSUM errors ??!?!?!?!!??
27 matches
Mail list logo
