On Wed, Jul 03, 2013 at 11:37:09AM +0900, Tomasz Chmielewski wrote:
> I've upgraded to linux 3.10 and enabled extended inode refs and skinny
> metadata extent refs with these commands:
>
> btrfstune -r /dev/sdc1
> btrfstune -x /dev/sdc1
>
> Since then, I have "WARNING: at fs/btrfs/backref.c:903
commit 47fb091fb787420cd195e66f162737401cce023f(Btrfs: fix unlock after free on
rewinded tree blocks)
takes an extra increment on the reference of allocated dummy extent buffer, so
now we
cannot free this dummy one, and end up with extent buffer leak.
Signed-off-by: Liu Bo
---
fs/btrfs/ctree.c
On Tue, Jul 02, 2013 at 11:51:21AM -0400, Eric Sandeen wrote:
> On Jul 2, 2013, at 10:28 AM, Koen De Wit
> wrote:
>
> > Dave,
> >
> > Thanks for the review. I will clean up the commit message and do
> > a full mail-to-myself-and-test-patch round trip to avoid errors
> > like the wrong test numbe
Sorry for multiple emails, however looking closely it appears
this will make btrfs_close_devices should be the last thing
in the thread, which means thread can not use the list after
calling btrfs_close_devices(). That would confuse.
Further not all threads using device_list_add() wou
further, you need to free device->label as well.
static int device_list_add(const char *path,
struct btrfs_super_block *disk_super,
u64 devid, struct btrfs_fs_devices **fs_devices_ret)
{
::
device->label = kstrdup(disk_super->label, GF
On Mon, Jul 01, 2013 at 04:12:27PM -0400, Josef Bacik wrote:
> There is another bug in the tree mod log stuff in that we're calling
> tree_mod_log_free_eb every single time a block is cow'ed. The problem with
> this
> is that if this block is shared by multiple snapshots we will call this
> mult
I've upgraded to linux 3.10 and enabled extended inode refs and skinny
metadata extent refs with these commands:
btrfstune -r /dev/sdc1
btrfstune -x /dev/sdc1
Since then, I have "WARNING: at fs/btrfs/backref.c:903
find_parent_nodes+0x616/0x815 [btrfs]()" showing up like crazy:
# grep -c "WARNI
于 2013年07月03日 01:26, David Sterba 写道:
That's a good cleanup, please send the kernel version as well.
david
I'll send the kernel patch asap.
--
-
Qu Wenruo
Development Dept.I
Nanjing Fujitsu Nanda Software Tech. Co., Ltd.(FNST)
No. 6 Wenzhu R
于 2013年07月03日 01:36, David Sterba 写道:
On Wed, Jun 26, 2013 at 01:27:08PM +0800, Qu Wenruo wrote:
--- a/btrfs-convert.c
+++ b/btrfs-convert.c
@@ -1802,7 +1802,7 @@ static int prepare_system_chunk_sb(struct
btrfs_super_block *super)
btrfs_set_stack_chunk_num_stripes(chunk, 1);
btr
On 07/02/2013 06:48 PM, Hugo Mills wrote:
So the damage probably happened then, if that stick is bad.
Filesystems have this irritating habit of remembering things done to
them across reboots. :) Hugo.
The previous action to the defrag was to delete 48 hours worth of
hourly snapshots. I was
This is similar to a previous fix I sent. 1 gig makes us do mixed file block
groups for btrfs, so these enospc tests will usually fail because we don't have
space for metadata, which is the case for this test. So jack the size up to
1.5gig so that btrfs can do its normal thing and pass the test.
On Tue, Jul 02, 2013 at 06:36:48PM +0100, Peter Chant wrote:
> On 07/02/2013 08:29 AM, Hugo Mills wrote:
> >This is usually an indication that you have bad hardware -- I'd
> >suggest testing RAM, PSU, CPU in that order. I'm not sure what, if
> >anything, can be done to fix the error on the disk rig
On Wed, Jun 26, 2013 at 01:27:08PM +0800, Qu Wenruo wrote:
> --- a/btrfs-convert.c
> +++ b/btrfs-convert.c
> @@ -1802,7 +1802,7 @@ static int prepare_system_chunk_sb(struct
> btrfs_super_block *super)
> btrfs_set_stack_chunk_num_stripes(chunk, 1);
> btrfs_set_stack_chunk_sub_stripes(ch
On 07/02/2013 08:29 AM, Hugo Mills wrote:
This is usually an indication that you have bad hardware -- I'd
suggest testing RAM, PSU, CPU in that order. I'm not sure what, if
anything, can be done to fix the error on the disk right now.
Thanks, appreciated.
Hmm. I've got one stick of ram out
That's a good cleanup, please send the kernel version as well.
david
--
To unsubscribe from this list: send the line "unsubscribe linux-btrfs" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
On Tue, Jun 25, 2013 at 09:02:13PM +0800, Wang Sheng-Hui wrote:
> +static void btrfs_close_device(struct btrfs_device *device)
> +{
> + close(device->fd);
> + device->fd = -1;
> + device->writeable = 0;
It's not necessary to set these variables when we're freeing the
structure immediat
On Sun, Jun 30, 2013 at 2:36 PM, Josef Bacik wrote:
> On Sun, Jun 30, 2013 at 11:29:14AM +0300, Alex Lyakas wrote:
>> Hi Josef,
>>
>> On Wed, Jun 26, 2013 at 5:16 PM, Alex Lyakas
>> wrote:
>> > Hi Josef,
>> > Can you please help me with another question.
>> >
>> > I am looking at your patch:
>> >
On Sat, Jun 22, 2013 at 03:13:42PM +0900, Kusanagi Kouichi wrote:
> $ make btrfs
...
> [CC] btrfs.o
> btrfs.c:24:21: fatal error: version.h: No such file or directory
> #include "version.h"
Not only the 'btrfs' target, but also mkfs.btrfs (both dynamic and
static) and the other targets th
On Sat, Jun 22, 2013 at 02:39:21PM +0900, Kusanagi Kouichi wrote:
> @@ -224,12 +224,10 @@ again:
> goto out;
> }
>
> - cpath = realpath(path, 0);
> - dname = strdup(cpath);
> + dname = strdup(path);
We want realpath() here, and when it returns NULL, there was an
e
On Jul 2, 2013, at 10:28 AM, Koen De Wit wrote:
> Dave,
>
> Thanks for the review. I will clean up the commit message and do a full
> mail-to-myself-and-test-patch round trip to avoid errors like the wrong test
> numbers in the golden output. I'm sorry for this.
>
> About cutting out file nam
On Tuesday, July 02, 2013 01:00:29 PM Duncan wrote:
> Just to be clear, your system, your call. I'd never /dream/ of
> interfering with that due to the implications for my own system (which is
> certainly highly customized even matched against a peer-group of other
> gentoo installs =:^). That sa
My recent truncate patch uncovered this bug, but I can reproduce it without the
truncate patch. If you mount with -o compress-force, do a direct write to some
area, do a buffered write to some other area, and then do a direct read you will
get the wrong data for where you did the buffered write.
Dave,
Thanks for the review. I will clean up the commit message and do a full
mail-to-myself-and-test-patch round trip to avoid errors like the wrong test
numbers in the golden output. I'm sorry for this.
About cutting out file names from the output. I did this in the first version
of the patc
When I run "btrfs filesystem balance", does this implicitly
defragment the filesystem? (Assuming there is plenty free space)
--
Paul Richards
@pauldoo
--
To unsubscribe from this list: send the line "unsubscribe linux-btrfs" in
the body of a message to majord...@vger.kernel.org
More majordomo inf
Shridhar Daithankar posted on Mon, 01 Jul 2013 21:49:16 +0530 as
excerpted:
> On Monday, July 01, 2013 09:10:41 AM Duncan wrote:
>>
>>> mouting with autodefrag is a serious degradation..
>>
>> It is? AFAIK, all the autodefrag mount option does is scan files for
>> fragmentation as they are writ
On Tue, 02 Jul 2013 10:56:18 +0100, Miguel Negrão wrote:
> Seg, 2013-07-01 às 17:50 +0200, Stefan Behrens escreveu:
>> What you are trying to do is not possible, it is not supported.
>>
>> Btrfs send/receive can be used to create backups. The use case to
>> restore from backups is not addressed.
>>
On Tue, Jul 02, 2013 at 11:27:51AM +0200, Koen De Wit wrote:
> This testscript creates reflinks to files on different subvolumes, overwrites
> the original files and reflinks, and moves reflinked files between subvolumes.
>
> Originally submitted as testcase 302, changes are made based on comment
Seg, 2013-07-01 às 17:50 +0200, Stefan Behrens escreveu:
What you are trying to do is not possible, it is not supported.
>
> Btrfs send/receive can be used to create backups. The use case to
> restore from backups is not addressed.
>
Ok, I see, but then I think I don't understand how btrfs send r
Thanks Eric for reviewing and improving testcases btrfs/306, 309, 310 and 311 !
I had just one comment: on line 70 the output was redirected to $seqres.fll
instead of $seqres.full. Corrected patch below.
# Check if creating a sparse copy ("reflink") of a file on btrfs
# expectedly fails when it'
This testscript creates reflinks to files on different subvolumes, overwrites
the original files and reflinks, and moves reflinked files between subvolumes.
Originally submitted as testcase 302, changes are made based on comments from
Eric: http://oss.sgi.com/archives/xfs/2013-03/msg00231.html
T
(resent to list)
On Mon, July 01, 2013 at 22:12 (+0200), Josef Bacik wrote:
> There is another bug in the tree mod log stuff in that we're calling
> tree_mod_log_free_eb every single time a block is cow'ed. The problem with
> this
> is that if this block is shared by multiple snapshots we will c
On Mon, July 01, 2013 at 22:25 (+0200), Josef Bacik wrote:
> Previously we held the tree mod lock when adding stuff because we use it to
> check and see if we truly do want to track tree modifications. This is
> admirable, but GFP_ATOMIC in a critical area that is going to get hit pretty
> hard an
On Mon, Jul 01, 2013 at 11:56:30PM +0100, Peter Chant wrote:
> Sirs,
>
> my recently slowing file system is now going read only after trying
> a defrag or other operation. I'm wondering whether this is the
> result of a hardware failure or a btrfs or some other issue. Output
> of dmesg:
[snip]
On Sun, June 30, 2013 at 15:55 (+0200), Josef Bacik wrote:
> On Sun, Jun 30, 2013 at 10:25:05AM +0200, Jan Schmidt wrote:
>> On 30.06.2013 05:17, Josef Bacik wrote:
>>> We need to hold the tree mod log lock in __tree_mod_log_rewind since we walk
>>> forward in the tree mod entries, otherwise we'll
34 matches
Mail list logo
