On 23.10.2017 23:57, Liu Bo wrote:
> Currently drop_caches is used to invalidate file's page cache so that
> buffered read can hit disk, but the problem is that it may also
> invalidate metadata's page cache, so the test case may not get read
> errors (and repair) if reading metadata has
> Does anyone know why scrub did not catch these errors that show up in dmesg?
Can you try offline scrub from this repo
https://github.com/gujx2017/btrfs-progs/tree/offline_scrub and see
whether it
detects the issue? "btrfs scrub start --offline "
Cheers,
Lakshmipathi.G
On 10/23/2017 12:45 PM, Misono, Tomohiro wrote:
Currently "fi usage" (and "dev usage") cannot run for the filesystem using
seed device.
This is because FS_INFO ioctl returns the number of devices excluding
seeds, but load_device_info() tries to access valid device from devid 0
to max_id, and
On 10/23/2017 12:44 PM, Misono, Tomohiro wrote:
Move dev_to_fsid() from cmds-filesystem.c to cmds-fi-usage.c in order to
call it from both "fi show" and "fi usage".
Signed-off-by: Tomohiro Misono
Reviewed-by: Anand Jain
Thanks, Anand
All three devices completed the 'long' SMART selftest without error:
# 1 Extended offlineCompleted without error 00%
Here is the standard data that I forgot to include in my first message:
Running Arch linux
$ uname -a
Linux HOSTNAME 4.9.56-1-lts #1 SMP Thu Oct 12 22:34:15 CEST 2017
We need to call extent_range_clear_dirty_for_io()
on compression range to prevent application from changing
page content, while pages compressing.
extent_range_clear_dirty_for_io() run on each loop iteration,
"(end - start)" can be much (up to 1024 times) bigger
then compression range
Currently drop_caches is used to invalidate file's page cache so that
buffered read can hit disk, but the problem is that it may also
invalidate metadata's page cache, so the test case may not get read
errors (and repair) if reading metadata has consumed the injected
faults.
This changes it to do
On , ein wrote:
> On 10/23/2017 10:39 AM, Wolf wrote:
> > [...]
> >
> > Is this and issue somewhere inside btrfs or is disk HW related problem?
>
> Highly unlikely hardware related. According to SMART and dmsg, there's
> no indication which would suggest disk failure.
That's my thinking too (and
On , Qu Wenruo wrote:
> [27240.680874] perf: interrupt took too long (3952 > 3942), lowering
> kernel.perf_event_max_sample_rate to 50400
> > [30658.875802] BTRFS warning (device dm-12): checksum error at logical
> > 37889245122560 on dev /dev/mapper/data7, sector 2743145096, root 23674,
> >
2017-10-22 16:44 GMT+03:00 Timofey Titovets :
> 2017-10-20 16:45 GMT+03:00 David Sterba :
>> On Fri, Oct 20, 2017 at 01:48:01AM +0300, Timofey Titovets wrote:
>>> 2017-10-19 18:39 GMT+03:00 David Sterba :
>>> > On Fri, Sep 29, 2017 at
On 10/23/2017 12:58 AM, Nikolay Borisov wrote:
> btrfs_rm_dev_item calls several function under an activa transaction, however
^^
active
> it fails to abort it if an error happens. Fix this by adding explicit
>
On 2017年10月23日 18:51, Nikolay Borisov wrote:
> btrfs_balance_delayed_items is the sole caller of btrfs_wq_run_delayed_node
> and
> already includes one of the checks whether the delayed inodes should be run.
> On
> the other hand btrfs_wq_run_delayed_node duplicates that check and performs an
On 2017年10月23日 18:51, Nikolay Borisov wrote:
> Currently btrfs_async_run_delayed_root's implementation uses 3 goto labels to
> mimic the functionality of a simple do {} while loop. Refactor the function
> to use a do {} while construct, making intention clear and code easier to
> follow. No
btrfs_balance_delayed_items is the sole caller of btrfs_wq_run_delayed_node and
already includes one of the checks whether the delayed inodes should be run. On
the other hand btrfs_wq_run_delayed_node duplicates that check and performs an
additional one for wq congestion.
Let's remove the
Currently btrfs_async_run_delayed_root's implementation uses 3 goto labels to
mimic the functionality of a simple do {} while loop. Refactor the function
to use a do {} while construct, making intention clear and code easier to
follow. No functional changes
Signed-off-by: Nikolay Borisov
On 10/23/2017 10:39 AM, Wolf wrote:
> [...]
>
> Is this and issue somewhere inside btrfs or is disk HW related problem?
Highly unlikely hardware related. According to SMART and dmsg, there's
no indication which would suggest disk failure.
--
To unsubscribe from this list: send the line
On 2017年10月23日 17:17, Qu Wenruo wrote:
>
>
> On 2017年10月23日 16:39, Wolf wrote:
>> Hi,
>> I'm having problem with corruption in one file on my disk array. This is
>> third time it happened (probably). First time I didn't checked the
>> offending file so I'm not sure but it's likely. Btrfs scrub
On 2017年10月23日 16:39, Wolf wrote:
> Hi,
> I'm having problem with corruption in one file on my disk array. This is
> third time it happened (probably). First time I didn't checked the
> offending file so I'm not sure but it's likely. Btrfs scrub finds the
> corruption, according to both dmesg
Hi,
I'm having problem with corruption in one file on my disk array. This is
third time it happened (probably). First time I didn't checked the
offending file so I'm not sure but it's likely. Btrfs scrub finds the
corruption, according to both dmesg and it's output it fixes it.
However, next run
Did you receive my previous email regarding your family inheritance ?
Andrew.
--
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
btrfs_rm_dev_item calls several function under an activa transaction, however
it fails to abort it if an error happens. Fix this by adding explicit
btrfs_abort_transaction/btrfs_end_transaction calls
Signed-off-by: Nikolay Borisov
---
V4:
* Reorder the code a bit to prevent
21 matches
Mail list logo