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
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 fi
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 and
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 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 "unsubscrib
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
---
fs/
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 duplicat
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 funct
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 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
> btrfs_abort_transaction/btrfs_end_t
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 06:22:00PM +0200, David Sterba wrote:
>>> >> On Thu, Sep 28, 201
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,
> > ino
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
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
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 (BTRFS_MAX_U
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
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
---
cmds-fi-usage.c | 29
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 r
> 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
http://www.giis.co.
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 consumed
Yes, it is finding much more than just one error.
>From dmesg
[89520.441354] BTRFS warning (device sdn): csum failed ino 4708 off
27529216 csum 2615801759 expected csum 874979996
$ sudo btrfs scrub start --offline --progress /dev/sdn
ERROR: data at bytenr 68431499264 mirror 1 csum mismatch, have
It's pointless to defer it to a kthread helper as we're not under a
special context.
For reference, commit 1f78160ce1b1 ("Btrfs: using rcu lock in the
reader side of devices list") introduced RCU freeing for device
structures.
Signed-off-by: Liu Bo
Reviewed-by: Anand Jain
---
v3: - Enhance cha
Compression code path has only flaged bios with REQ_OP_WRITE no matter
where the bios come from, but it could be a sync write if fsync starts
this writeback or a normal writeback write if wb kthread starts a
periodic writeback.
It breaks the rule that sync writes and writeback writes need to be
di
23 matches
Mail list logo
