2015-03-31 11:19 GMT+08:00 Omar Sandoval :
> On Tue, Mar 31, 2015 at 11:06:10AM +0800, Robbie Ko wrote:
>> Hi,
>>
>> I have testing btrfs send/receive recently.
>>
>> I got an error "send ioctl failed with -12: Cannot allocate memory" on
>> send side.
>> WARN_ON happened on "len > PATH_MAX" in fs_
On Tue, Mar 31, 2015 at 11:06:10AM +0800, Robbie Ko wrote:
> Hi,
>
> I have testing btrfs send/receive recently.
>
> I got an error "send ioctl failed with -12: Cannot allocate memory" on
> send side.
> WARN_ON happened on "len > PATH_MAX" in fs_path_ensure_buf.
>
> I got an error "utime failed
Hi,
I have testing btrfs send/receive recently.
I got an error "send ioctl failed with -12: Cannot allocate memory" on
send side.
WARN_ON happened on "len > PATH_MAX" in fs_path_ensure_buf.
I got an error "utime failed: No such file or directory" on receive side.
The followings are simple repro
I've been reading the wiki to help sort out an issue and learn more
about RAID. I wanted to download it to my local drive to read offlibe
and that facility sseems to not be there. I checked the mediawiki
version in the source and it is an LTS version for which support ends
in two months. Ar
Test cloning a file range with a length of zero into a destination offset
greater than zero.
This made btrfs create an extent state record with a start offset greater than
the end offset, resulting in chaos such as an infinite loop when evicting an
inode.
This issue was fixed by the following lin
Small update. I've done a strace of the qemu process, filtering for
pwrite,pwritev while the guest experiences these I/O errors and posted
it to the bug. Kevin Wolf looked at it and says
https://bugzilla.redhat.com/show_bug.cgi?id=1204569#c20
> There is one single failing pwritev() call in it:
>
On Wed, Jan 14, 2015 at 05:09:28PM -0700, Chris Murphy wrote:
> Following the trail backward leads to this one
> http://wiki.drewhess.com/wiki/Creating_an_encrypted_filesystem_on_a_partition
>
> Which has a subheading "md RAID array" that starts out:
>
> "If the device to be encrypted is an md RA
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On 3/30/15 3:29 PM, Filipe David Manana wrote:
> On Mon, Mar 30, 2015 at 8:12 PM, Jeff Mahoney
> wrote:
>> The block group removal patch adds an alternate path to forget
>> extents other than btrfs_finish_extent_commit. As a result, any
>> extents
On Mon, Mar 30, 2015 at 10:05 AM, Sophie Dexter
wrote:
On 24/03/15 17:34, Chris Mason wrote:
You have great timing, there are two reports of a very similar abort
with 4.0-rc5, but your report makes it clear these are not a
regression
from 4.0-rc4.
Are you able to run btrfsck on this files
Help welcomed...
Trying to delete one device from a btrfs raid1 across 3 devices gives
for my example:
btrfs device delete /dev/sdf5 /mnt/data2
ERROR: error removing the device '/dev/sdf5' - Inappropriate ioctl for
device
That part of the filesystem is:
Label: 'btrfs_data2' uuid: 3aaee716-
insert_inline_extent() checked for compressed_pages to be NULL then
it accessed it under compress_type != BTRFS_COMPRESS_NONE.
This patch adds BUG() when compress_size != 0, compress_type !=
BTRFS_COMPRESS_NONE and compresses_pages == 0.
Signed-off-by: Fabian Frederick
---
fs/btrfs/inode.c | 8 +
cow_file_range_inline() was called with 0 instead of
actual definition.
Signed-off-by: Fabian Frederick
---
fs/btrfs/inode.c | 7 ---
1 file changed, 4 insertions(+), 3 deletions(-)
diff --git a/fs/btrfs/inode.c b/fs/btrfs/inode.c
index 686331f..f626519 100644
--- a/fs/btrfs/inode.c
+++ b/f
On Mon, Mar 30, 2015 at 06:26:47PM +0100, Filipe Manana wrote:
> If we pass a length of 0 to the extent_same ioctl, we end up locking an
> extent range with a start offset greater then its end offset (if the
> destination file's offset is greater than zero). This results in a warning
> from extent_
On Mon, Mar 30, 2015 at 8:12 PM, Jeff Mahoney wrote:
> The block group removal patch adds an alternate path to forget extents
> other than btrfs_finish_extent_commit. As a result, any extents that would
> be freed when the block group is removed aren't discarded. In my
> test run, with a large cop
On Mon, Mar 30, 2015 at 06:23:59PM +0100, Filipe Manana wrote:
> If we attempt to clone a 0 length region into a file we can end up
> inserting a range in the inode's extent_io tree with a start offset
> that is greater then the end offset, which triggers immediately the
> following warning:
>
> [
The block group removal patch adds an alternate path to forget extents
other than btrfs_finish_extent_commit. As a result, any extents that would
be freed when the block group is removed aren't discarded. In my
test run, with a large copy of mixed sized files followed by removal, it
left nearly 2/3
The combination of mkfs.btrfs discarding the entire block device and the
old behavior of block groups being retained forever made iterating over
the block groups on disk for FITRIM an easy optimization. If there wasn't
a block group describing the space, btrfs had never written to it.
Since we now
This tests tests four conditions where discard can potentially not
discard unused extents completely.
We test, with -o discard and with fstrim, scenarios of removing many
relatively small files and removing several large files.
The important part of the two scenarios is that the large files must
On Mon, Mar 30, 2015 at 02:30:34PM +0200, David Sterba wrote:
> On Mon, Mar 30, 2015 at 02:02:17AM -0700, Omar Sandoval wrote:
> > Before commit bafc9b754f75 ("vfs: More precise tests in d_invalidate"),
> > d_invalidate() could return -EBUSY when a dentry for a directory had
> > more than one refer
Hi,
Just a follow up on this report.
The file system in question is a raid1 across 2x320G old Western Digital
WD3200KS.
I janked them out of the server to run a fsck on another computer (after
a proper shutdown).
One of the disks did not get properly detected on the secondary computer.
Hopef
If we pass a length of 0 to the extent_same ioctl, we end up locking an
extent range with a start offset greater then its end offset (if the
destination file's offset is greater than zero). This results in a warning
from extent_io.c:insert_state through the following call chain:
btrfs_extent_sam
Test cloning a file range with a length of zero into a destination offset
greater than zero.
This made btrfs create an extent state record with a start offset greater than
the end offset, resulting in chaos such as an infinite loop when evicting an
inode.
This issue was fixed by the following lin
If we attempt to clone a 0 length region into a file we can end up
inserting a range in the inode's extent_io tree with a start offset
that is greater then the end offset, which triggers immediately the
following warning:
[ 3914.619057] WARNING: CPU: 17 PID: 4199 at fs/btrfs/extent_io.c:435
inser
This test tests three conditions where orphan items need to be cleaned up:
1) Default subvolume is fs tree root (mkfs default)
2) Default subvolume has been set explicitly to another subvolume (set-default)
3) Looking up a subvolume during a traversal
In the kernel, these three cases use separate
On 30/03/2015 16:25, David Sterba wrote:
> On Wed, Mar 25, 2015 at 11:55:36AM +0100, Marc Cousin wrote:
>> On 25/03/2015 02:19, David Sterba wrote:
>>> Snapper might add to that if you have
>>>
>>> EMPTY_PRE_POST_CLEANUP="yes"
>>>
>>> as it reads the pre/post snapshots and deletes them if the diff
On Wed, Mar 25, 2015 at 07:38:20AM -0400, Rich Freeman wrote:
> On Wed, Mar 25, 2015 at 6:55 AM, Marc Cousin wrote:
> > On 25/03/2015 02:19, David Sterba wrote:
> >> as it reads the pre/post snapshots and deletes them if the diff is
> >> empty. This adds some IO stress.
> >
> > I couldn't find a c
On Wed, Mar 25, 2015 at 11:55:36AM +0100, Marc Cousin wrote:
> On 25/03/2015 02:19, David Sterba wrote:
> > Snapper might add to that if you have
> >
> > EMPTY_PRE_POST_CLEANUP="yes"
> >
> > as it reads the pre/post snapshots and deletes them if the diff is
> > empty. This adds some IO stress.
>
I am using 3.19.3 kernel, v3.19-rc2 btrfs-progs and v0.09-1 duperemove.
I have a btrfs lzo-compressed /home volume and I ran
duperemove -rdhv /home
It took over a day (no problem for me, it was a quiet time and it's a vm
on so-so underlying hardware), and it reported lots of matched extents.
On 24/03/15 17:34, Chris Mason wrote:
You have great timing, there are two reports of a very similar abort
with 4.0-rc5, but your report makes it clear these are not a regression
from 4.0-rc4.
Are you able to run btrfsck on this filesystem? I'd like to check for
metadata inconsistencies.
-chri
On Sat, Mar 28, 2015 at 04:02:06AM -0700, Omar Sandoval wrote:
> Whenever the check for a send in progress introduced in commit
> 521e0546c970 (btrfs: protect snapshots from deleting during send) is
> hit, we return without unlocking inode->i_mutex. This is easy to see
> with lockdep enabled:
>
>
On Sat, Mar 28, 2015 at 11:37:43AM +, Filipe David Manana wrote:
> On Sat, Mar 28, 2015 at 11:02 AM, Omar Sandoval wrote:
> > Whenever the check for a send in progress introduced in commit
> > 521e0546c970 (btrfs: protect snapshots from deleting during send) is
> > hit, we return without unloc
On Fri, Mar 27, 2015 at 02:58:43PM -0700, Zach Brown wrote:
> Harald suggested that we remove the message from the fake fsck.btrfs
> that some distros run at boot:
>
> https://bugzilla.redhat.com/show_bug.cgi?id=1206502
>
> "This output does not add anything, but is a disturbing element of
> bo
On Mon, Mar 30, 2015 at 02:02:17AM -0700, Omar Sandoval wrote:
> Before commit bafc9b754f75 ("vfs: More precise tests in d_invalidate"),
> d_invalidate() could return -EBUSY when a dentry for a directory had
> more than one reference to it. This is what prevented a mounted
> subvolume from being de
On Mon, 30 Mar 2015 08:16:44 +0200, Juan Orti Alcaine wrote:
> El 2015-03-29 22:04, Holger Hoffstätte escribió:
>> On Sun, 29 Mar 2015 13:40:56 -0600, Chris Murphy wrote:
>>
>>> On Sun, Mar 29, 2015 at 1:15 PM, Juan Orti Alcaine
>>> wrote:
>>>
The filesystem was created with one device, an
On 30.03.2015 12:02, Omar Sandoval wrote:
Before commit bafc9b754f75 ("vfs: More precise tests in d_invalidate"),
d_invalidate() could return -EBUSY when a dentry for a directory had
more than one reference to it. This is what prevented a mounted
subvolume from being deleted, as struct vfsmount h
Before commit bafc9b754f75 ("vfs: More precise tests in d_invalidate"),
d_invalidate() could return -EBUSY when a dentry for a directory had
more than one reference to it. This is what prevented a mounted
subvolume from being deleted, as struct vfsmount holds a reference to
the subvolume dentry. Ho
36 matches
Mail list logo
