On Mon, Jun 22, 2015 at 5:35 AM, Timofey Titovets nefelim...@gmail.com 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
On Mon, Jun 22, 2015 at 10:36 AM, Timofey Titovets nefelim...@gmail.com wrote:
2015-06-22 19:03 GMT+03:00 Chris Murphy li...@colorremedies.com:
On Mon, Jun 22, 2015 at 5:35 AM, Timofey Titovets nefelim...@gmail.com
wrote:
Okay, logs, i did release disk /dev/sde1 and get:
Jun 22 14:28:40
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
2015-06-22 19:03 GMT+03:00 Chris Murphy li...@colorremedies.com:
On Mon, Jun 22, 2015 at 5:35 AM, Timofey Titovets nefelim...@gmail.com
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
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
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,
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 well?
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
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
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:
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
-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
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,
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 mfas...@suse.de
Reviewed-by: David Sterba dste...@suse.cz
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
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 mfas...@suse.de
---
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 gar...@cerberos.id.au 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
On Mon, Jun 22, 2015 at 10:08 AM, Robbie Ko robbi...@synology.com 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
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
On Mon, Jun 22, 2015 at 10:08 AM, Robbie Ko robbi...@synology.com 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:
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:
On Mon, Jun 22, 2015 at 10:08 AM, Robbie Ko robbi...@synology.com 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
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
Avoid the overhead of allocating an orphan_dir_info object unnecessarily.
Signed-off-by: Robbie Ko robbi...@synology.com
---
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
---
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
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)
Signed-off-by: Anand Jain anand.j...@oracle.com
---
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
On Mon, Jun 22, 2015 at 10:08 AM, Robbie Ko robbi...@synology.com 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
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
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)
|
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 case
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:
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
This
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
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
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.
Can
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
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 mount
There is no need of NULL check before kfree,
removing the same
Signed-off-by: Maninder Singh maninder...@samsung.com
Reviewed-by: Akhilesh Kumar akhiles...@samsung.com
---
fs/btrfs/free-space-cache.c |6 ++
1 file changed, 2 insertions(+), 4 deletions(-)
diff --git
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
On Mon, Jun 22, 2015 at 06:18:32PM +0800, Anand Jain wrote:
Signed-off-by: Anand Jain anand.j...@oracle.com
Tested-by: David Sterba dste...@suse.cz
Thanks, fixes the crash in the sysfs update patchset.
--
To unsubscribe from this list: send the line unsubscribe linux-btrfs in
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 quwen...@cn.fujitsu.com
Thanks, both applied with minor
42 matches
Mail list logo
