There is no need of NULL check before kfree,
removing the same
Signed-off-by: Maninder Singh
Reviewed-by: Akhilesh Kumar
---
fs/btrfs/free-space-cache.c |6 ++
1 file changed, 2 insertions(+), 4 deletions(-)
diff --git a/fs/btrfs/free-space-cache.c b/fs/btrfs/free-space-cache.c
index 9
OpenSuSE 13.2 system with single BTRFS / mounted on top of /dev/md1.
/dev/md1 is md raid5 across 4 SATA disks.
System details are:
Linux suse132 4.0.5-4.g56152db-default #1 SMP Thu Jun 18 15:11:06 UTC
2015 (56152db) x86_64 x86_64 x86_64 GNU/Linux
btrfs-progs v4.1+20150622
Label: none
On Sat, Jun 20, 2015 at 04:53:24PM +0200, Christoph Biedl wrote:
> Hi there,
>
> I'm having trouble with btrfs where removing a snapshot causes a
> kernel Oops at blk_get_backing_dev_info+0x10/0x1c (plus or minus a
> byte bytes). Is this a known issue? Else I'll dig further. Stack
> traces below.
Hi,
I have tested your PATCH v2 , but something wrong happened.
kernel: 4.1.0-rc7+ with your five patches
vitrualBox ubuntu14.10-server + LVM
I make a new btrfs.ko with your patches,
rmmod original module and insmod the new.
When I use the profile RAID1/10, mkfs successfully
But when mount the
Tsutomu Itoh wrote on 2015/06/23 08:55 +0900:
On 2015/06/23 3:18, Christian Robottom Reis wrote:
On Mon, Jun 22, 2015 at 05:00:23PM +0200, David Sterba wrote:
- qgroup:
- show: distinguish no limits and 0 limit value
- limit: ability to clear the limit
I'm using kernel 4.1-rc7
Vianney Stroebel wrote on 2015/06/19 01:55 +0200:
One of my btrfs partition seems to have been corrupted.
Since I've tried to balance it, I can only mount it read-only. I have
been able to use it read-only without problem so far so the data seems
safe.
When I remove the "ro" option, the "moun
On 2015/06/23 3:18, Christian Robottom Reis wrote:
On Mon, Jun 22, 2015 at 05:00:23PM +0200, David Sterba wrote:
- qgroup:
- show: distinguish no limits and 0 limit value
- limit: ability to clear the limit
I'm using kernel 4.1-rc7 as per:
root@riff:/var/lib/lxc/juju-trusty-
I can confirm that convert works now with 4.1 kernel and btrfs-progs
Suman
On Tue, Jun 9, 2015 at 10:31 PM, Gareth Pye wrote:
> btrfs has a small bug at the moment where balance can't convert raid
> levels (it just does nothing), it is meant to be fixed with the next
> kernel release.
>
> On Wed
Clone and extent same lock their source and target inodes in opposite order.
In addition to this, the range locking in clone doesn't take ordering into
account. Fix this by having clone use the same locking helpers as
btrfs-extent-same.
In addition, I do a small cleanup of the locking helpers, rem
->readpage() does page_lock() before extent_lock(), we do the opposite in
extent-same. We want to reverse the order in btrfs_extent_same() but it's
not quite straightforward since the page locks are taken inside
btrfs_cmp_data().
So I split btrfs_cmp_data() into 3 parts with a small context struc
One issue users have reported is that dedupe changes mtime on files,
resulting in tools like rsync thinking that their contents have changed when
in fact the data is exactly the same. Clone still wants an mtime change, so
we special case this in the code.
With this patch an application can pass th
clone() supports cloning within an inode so extent-same can do
the same now. This patch fixes up the locking in extent-same to
know about the single-inode case. In addition to that, we add a
check for overlapping ranges, which clone does not allow.
Signed-off-by: Mark Fasheh
---
fs/btrfs/ioctl.c
In the case that we dedupe the tail of a file, we might expand the dedupe
len out to the end of our last block. We don't want to compare data past
i_size however, so pass the original length to btrfs_cmp_data().
Signed-off-by: Mark Fasheh
Reviewed-by: David Sterba
---
fs/btrfs/ioctl.c | 3 ++-
Hi Chris,
The following patches are based on top of my patch titled "btrfs:
Handle unaligned length in extent_same" which you have in your
'integration-4.2' branch:
https://git.kernel.org/cgit/linux/kernel/git/mason/linux-btrfs.git/commit/?id=e1d227a42ea2b4664f94212bd1106b9a3413ffb8
I sent o
On Mon, Jun 22, 2015 at 05:00:23PM +0200, David Sterba wrote:
> - qgroup:
> - show: distinguish no limits and 0 limit value
> - limit: ability to clear the limit
I'm using kernel 4.1-rc7 as per:
root@riff:/var/lib/lxc/juju-trusty-lxc-template/rootfs# uname -a
Linux riff 4.1.0-04
On Mon, Jun 22, 2015 at 05:00:23PM +0200, David Sterba wrote:
> - qgroup:
> - show: distinguish no limits and 0 limit value
> - limit: ability to clear the limit
I'm using kernel 4.1-rc7 as per:
root@riff:/var/lib/lxc/juju-trusty-lxc-template/rootfs# uname -a
Linux riff 4.1.0-04
Wow, nice collection of changes!
Am Montag, 22. Juni 2015, 17:00:23 schrieb David Sterba:
> * new
> - rescure zero-log
> - btrfsune:
> - rewrite uuid on a filesystem image
> - new option to turn on NO_HOLES incompat feature
Did you think about folding btrfstune into btrfs command as w
On Thu, Jun 18, 2015 at 04:38:56PM +0200, David Sterba wrote:
> Moving the discussion to fsdevel.
>
> Summary: disabling MS_I_VERSION brings some speedups to btrfs, but the
> generic 'noiversion' option cannot be used to achieve that. It is
> processed before it reaches btrfs superblock callback,
On Mon, Jun 22, 2015 at 06:18:35PM +0200, Goffredo Baroncelli wrote:
> Many thanks for your work.
> BTW just for curiosity: is it a coincidence that both Torvalds and you
> released the kernel 4.1/btrfs-progs 4.1 in the same day ? I know that
> the version are coupled, but also the same day
Th
On Mon, Jun 22, 2015 at 10:36 AM, Timofey Titovets wrote:
> 2015-06-22 19:03 GMT+03:00 Chris Murphy :
>> On Mon, Jun 22, 2015 at 5:35 AM, Timofey Titovets
>> wrote:
>>> Okay, logs, i did release disk /dev/sde1 and get:
>>> Jun 22 14:28:40 srv-lab-ceph-node-01 kernel: Read(10): 28 00 11 1d 69
>>>
2015-06-22 19:03 GMT+03:00 Chris Murphy :
> On Mon, Jun 22, 2015 at 5:35 AM, Timofey Titovets
> wrote:
>> Okay, logs, i did release disk /dev/sde1 and get:
>> Jun 22 14:28:40 srv-lab-ceph-node-01 kernel: Read(10): 28 00 11 1d 69
>> 00 00 00 08 00
>> Jun 22 14:28:40 srv-lab-ceph-node-01 kernel: bl
On 2015-06-22 17:00, David Sterba wrote:
> Hi,
Many thanks for your work.
BTW just for curiosity: is it a coincidence that both Torvalds and you released
the kernel 4.1/btrfs-progs 4.1 in the same day ? I know that the version are
coupled, but also the same day
BR
G.Baronelli
>
> btrfs-pr
On Mon, Jun 22, 2015 at 5:35 AM, Timofey Titovets wrote:
> Okay, logs, i did release disk /dev/sde1 and get:
> Jun 22 14:28:40 srv-lab-ceph-node-01 kernel: Read(10): 28 00 11 1d 69
> 00 00 00 08 00
> Jun 22 14:28:40 srv-lab-ceph-node-01 kernel: blk_update_request: I/O
> error, dev sde, sector 2871
Hi,
btrfs-progs 4.1 have been released (in time with kernel 4.1). Unusual load of
changes.
Fixed since rc1:
- uuid rewrite prints the correct original UUID
- map-logical updated
- fi show size units
- typos
* bugfixes
- fsck.btrfs: no bash-isms
- bugzilla 97171: invalid memory access
On Thu, Jun 18, 2015 at 02:46:11PM +0800, Qu Wenruo wrote:
> Now "filesystem show" command can handle different units now.
>
> This is handy for higher level programs to get accurate output from "fi
> show" command.
>
> Signed-off-by: Qu Wenruo
Thanks, both applied with minor fixups.
--
To unsu
On Mon, Jun 22, 2015 at 06:18:32PM +0800, Anand Jain wrote:
> Signed-off-by: Anand Jain
Tested-by: David Sterba
Thanks, fixes the crash in the sysfs update patchset.
--
To unsubscribe from this list: send the line "unsubscribe linux-btrfs" in
So, in the btrfs mailing list, nobody will help a user who has had a whole
partition corrupted? I think my report was clear and complete.
In IRC, the only answer I got was: "format your partition, there's nothing you can
do and there's nothing to understand from this" (from nice people I should
And again if i've try
echo 1 > /sys/block/sdf/device/delete
Jun 22 14:44:16 srv-lab-ceph-node-01 kernel: [ cut here
]
Jun 22 14:44:16 srv-lab-ceph-node-01 kernel: kernel BUG at
/build/buildd/linux-3.19.0/fs/btrfs/extent_io.c:2056!
Jun 22 14:44:16 srv-lab-ceph-node-01 kernel
On Mon, Jun 22, 2015 at 10:08 AM, Robbie Ko wrote:
> There's one case where we can't issue a utimes operation for a directory.
There's one where we attempt to get utimes from a directory that
doesn't exist in the send snapshot.
> First, 261 can't move to d/item1 without the rename of inode 265.
On Mon, Jun 22, 2015 at 10:08 AM, Robbie Ko wrote:
> There's one more case where we can't issue a rename operation for a directory
> as soon as we process it. We move a directory from ancestor to descendant.
>
> | a
> | b
> | c
> | d
> "Move a directory fro
Okay, logs, i did release disk /dev/sde1 and get:
Jun 22 14:28:40 srv-lab-ceph-node-01 kernel: Read(10): 28 00 11 1d 69
00 00 00 08 00
Jun 22 14:28:40 srv-lab-ceph-node-01 kernel: blk_update_request: I/O
error, dev sde, sector 287140096
Jun 22 14:28:40 srv-lab-ceph-node-01 kernel: mptbase: ioc0:
Lo
On Mon, Jun 22, 2015 at 10:08 AM, Robbie Ko wrote:
> Base on [PATCH] Btrfs: incremental send, check if orphanized dir inode needs
> delayed rename
This is mentioned on the cover letter, so no need to repeat this on
the commit message of every patch in the series.
>
> Example1:
> There's one cas
On Mon, Jun 22, 2015 at 10:08 AM, Robbie Ko wrote:
> This reverts commit 5f806c3ae2ff6263a10a6901f97abb74dac03d36.
>
So, this is a revert patch that alone by itself doesn't fix any problem. Fine.
However you are now pasting below the commit message from another
patch in the series (patch 3) that
Signed-off-by: Anand Jain
---
fs/btrfs/sysfs.c | 8 +---
1 file changed, 5 insertions(+), 3 deletions(-)
diff --git a/fs/btrfs/sysfs.c b/fs/btrfs/sysfs.c
index ea81a05..603b0cc 100644
--- a/fs/btrfs/sysfs.c
+++ b/fs/btrfs/sysfs.c
@@ -523,9 +523,11 @@ static void __btrfs_sysfs_remove_fsid(str
There's one case where we leak a orphan_dir_info structure.
Example:
Parent snapshot:
| a/ (ino 279)
| c (ino 282)
| del/ (ino 281)
| tmp/ (ino 280)
| long/ (ino 283)
| longlong/ (ino 284)
Send snapshot:
| a/ (ino 279)
| long (ino 283)
|---
There's one case where we can't issue a utimes operation for a directory.
First, 261 can't move to d/item1 without the rename of inode 265. So as 262.
Thus 261 and 262 need to wait for rename.
Second, since 263 will be deleted and there are two waiting sub-directory
261 and 262, rmdir_ino of 261 wi
Avoid the overhead of allocating an orphan_dir_info object unnecessarily.
Signed-off-by: Robbie Ko
---
fs/btrfs/send.c | 13 ++---
1 file changed, 6 insertions(+), 7 deletions(-)
diff --git a/fs/btrfs/send.c b/fs/btrfs/send.c
index 579a4c8..9c60421 100644
--- a/fs/btrfs/send.c
+++ b/fs/
This reverts commit 5f806c3ae2ff6263a10a6901f97abb74dac03d36.
Btrfs: incremental send, avoid ancestor rename to descendant
There's one more case where we can't issue a rename operation for a directory
as soon as we process it. We move a directory from ancestor to descendant.
| a
| b
Base on [PATCH] Btrfs: incremental send, check if orphanized dir inode needs
delayed rename
Example1:
There's one case where we can't issue a rename operation for a directory
as soon as we process it. Used to delay directory renames if
wait_parent_move or wait_for_dest_dir_move, maybe cause circu
There's one case where we attempt to rmdir a directory prematurely.
Example:
Parent snapshot:
| a/ (ino 279)
| c (ino 282)
| del/ (ino 281)
| tmp/ (ino 280)
| long/ (ino 283)
Send snapshot:
| a/ (ino 279)
| long (ino 283)
| c/ (ino 282)
| t
There's one more case where we can't issue a rename operation for a directory
as soon as we process it. We move a directory from ancestor to descendant.
| a
| b
| c
| d
"Move a directory from ancestor to descendant" means moving dir. a into dir. c
This cas
Patch for fix btrfs send receive. These patches base on v4.1
plus following patches.
[PATCH] Btrfs: incremental send, don't delay directory renames unnecessarily
[PATCH] Btrfs: incremental send, check if orphanized dir inode needs delayed
rename
Thanks.
Robbie Ko (7):
Revert "Btrfs: incrementa
42 matches
Mail list logo
