Sometimes I got kernel NULL pointer warning like:
[ 778.248521] BUG: unable to handle kernel NULL pointer dereference at
05f0
[ 778.249728] IP: generic_make_request_checks+0x4d/0x610
And the address 0x5f0 is just ((struct block_device *)0)->bd_disk->queue.
I added some extra WAR
Filipe Manana 於 2017-01-04 21:07 寫到:
On Wed, Jan 4, 2017 at 10:53 AM, robbieko
wrote:
From: Robbie Ko
Test that an incremental send operation dosen't work because
dosen't -> doesn't
it tries to rename a directory which is already deleted.
This test exercises scenarios used to fail in btr
[root@f25h mnt]# btrfs fi du -s home.20170104
Total Exclusive Set shared Filename
ERROR: cannot check space of 'home.20170104': Inappropriate ioctl for device
The command works on this snapshot's parent.
kernel 4.8.15
btrfs-progs 4.8.5
What's interesting is the pa
Filipe Manana 於 2017-01-04 21:09 寫到:
On Wed, Jan 4, 2017 at 10:53 AM, robbieko
wrote:
From: Robbie Ko
Test that an incremental send operation dosen't' work because
it tries to update the time to a deleted directory after it finishes
a move operation.
The other one is that an operation is app
At 01/05/2017 09:46 AM, Bruce Guenter wrote:
In the man page for btrfs subvolume delete, the --commit-after option
says it will "wait for transaction commit at the end of the operation".
However, the available disk space continues to increase for several
minutes after this command completes.
In the man page for btrfs subvolume delete, the --commit-after option
says it will "wait for transaction commit at the end of the operation".
However, the available disk space continues to increase for several
minutes after this command completes. I am running linux kernel 4.4.35
on Gentoo Linux
Le 2017-01-03 07:11, Qu Wenruo a écrit :
Hello, what’s the status of my report since last October ?
thanks,
Sorry for the late reply.
I tried your image but...
It's so slow, no matter the mode I'm using.
So I'm not sure if it's a deadlock since lowmem mode still takes
several minuts and ju
I separated these 9 camera storages into 9 subvolumes (so now I have
10 subvols in total in this filesystem with the "root" subvol). It's
obviously way too early to talk about long term performance but now I
can tell that recursive defrag does NOT descend into "child"
subvolumes (it does not pick u
Hi Qu,
Am 01.01.2017 um 10:32 schrieb Qu Wenruo:
> Hi Stefan,
>
> I'm trying to push it to for-next (will be v4.11), but no response yet.
>
> It would be quite nice for you to test the following git pull and give
> some feedback, so that we can merge it faster.
>
> https://mail-archive.com/linu
Hi All,
I seem to have a similar issue to a subject in December:
Subject: page allocation stall in kernel 4.9 when copying files from one
btrfs hdd to another
In my case, this is caused when rsync'ing large amounts of data over NFS
to the server with the BTRFS file system. This was not appa
On Tue, Jan 03, 2017 at 04:34:31PM +0100, Lakshmipathi.G wrote:
> Will include other fields, if this gets accepted.
>
> Signed-off-by: Lakshmipathi.G
> ---
> btrfs-corrupt-block.c | 8
> 1 file changed, 8 insertions(+)
>
> diff --git a/btrfs-corrupt-block.c b/btrfs-corrupt-block.c
> in
Thank you for the information / clarifications. This helps me to
understand the operation somewhat better. I will continue to deal with
the subject.
Regardless of this, i will change the structure of my data in my
usecase and put on rsync --inplace --no-whole-file.
2017-01-04 13:58 GMT+01:00 Aust
I think we can achieve above help string with the help of custom usage
function instead of using argparse default usage. I'll check and send
a new patch.
Cheers,
Lakshmipathi.G
FOSS Programmer.
www.giis.co.in
On Wed, Jan 4, 2017 at 6:14 AM, Qu Wenruo wrote:
> What about changing current h
On Wed, Jan 4, 2017 at 10:53 AM, robbieko wrote:
> From: Robbie Ko
>
> Test that an incremental send operation dosen't' work because
> it tries to update the time to a deleted directory after it finishes
> a move operation.
>
> The other one is that an operation is applied to a file using the old
On Wed, Jan 4, 2017 at 10:53 AM, robbieko wrote:
> From: Robbie Ko
>
> Test that an incremental send operation dosen't work because
dosen't -> doesn't
> it tries to rename a directory which is already deleted.
>
> This test exercises scenarios used to fail in btrfs and are fixed by
> the follow
On 2017-01-03 16:35, Peter Becker wrote:
As i understand the duperemove source-code right (i work on/ try to
improve this code since 5 or 6 weeks on multiple parts), duperemove
does hashing and calculation before they call extend_same.
Duperemove stores all in a hashfile and read this. after all
On 01/04/17 00:21, David Sterba wrote:
On Wed, Dec 21, 2016 at 03:42:07PM +0800, Anand Jain wrote:
Both BTRFS_IOC_DEFRAG and BTRFS_IOC_DEFRAG_RANGE call the same
function- btrfs_ioctl_defrag(), however BTRFS_IOC_DEFRAG does
not support any argument, so check that and return not supported
if pr
From: Robbie Ko
Test that an incremental send operation dosen't work because
it tries to rename a directory which is already deleted.
This test exercises scenarios used to fail in btrfs and are fixed by
the following patch for the linux kernel:
"Btrfs: incremental send, add generation check for
From: Robbie Ko
Test that an incremental send operation dosen't' work because
it tries to update the time to a deleted directory after it finishes
a move operation.
The other one is that an operation is applied to a file using the old
name not the new name.
This test exercises scenarios used to
From: Robbie Ko
Test that an incremental send operation doesn't work because
there's a name collision in the destination and it's not checked
corretly before the rename operation applies.
This test exercises scenarios used to fail in btrfs and are fixed by
the following patch for the linux kerne
From: Robbie Ko
Test that an incremental send operation doesn't work for rmdir
because it uses the wrong name to delete.
This test exercises scenarios used to fail in btrfs and are fixed by
the following patch for the linux kernel:
"Btrfs: incremental send, skip check overwritten if parents' ge
From: Robbie Ko
Patch for test btrfs incremental send.
V3: remove "run_" based helpers
V2: improve the change log
Robbie Ko (4):
xfstests: btrfs/131: add test for an incremental send with name
collision
xfstests: btrfs/132: add test for invaild update time by an
incremental send
x
The expression is open-coded in several places, this asks for a wrapper.
As we know the MAX_EXTENT fits to u32, we can use the appropirate
division helper. This cascades to the result type updates.
Compiler is clever enough to use shift instead of integer division, so
there's no change in the gene
On Wed, Jan 04, 2017 at 04:37:08PM +0800, Qu Wenruo wrote:
> Test case like generic/304 and generic/158 can cause false alert due to
> the error output change of xfs_io.
>
> For error case, xfs_io mostly reports error like "dedupe: ERROR STRING"
> while under certain case, it reports error like "X
Test case like generic/304 and generic/158 can cause false alert due to
the error output change of xfs_io.
For error case, xfs_io mostly reports error like "dedupe: ERROR STRING"
while under certain case, it reports error like "XFS_IOC_FILE_EXTENT_SAME:
ERROR STRING".
Fix it by adding a new filte
25 matches
Mail list logo
