Re: slow single -> raid1 conversion (heavy write to original LVM volume)

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



Hello Chris,

here it is:  http://www.uschovna.cz/en/zasilka/TWGCD2G39WBH9G8N-XFE ;
(since I have limited journald space, beginning of events was
overwritten already, so it's assembled from syslog files)

jn


current device & fs usage:

root@sopa:~# btrfs dev usa /data
/dev/mapper/sopa-data, ID: 1
   Device size:             1.86TiB
   Device slack:              0.00B
   Data,single:             1.84TiB
   Metadata,single:         8.00MiB
   Metadata,DUP:           13.00GiB
   System,single:           4.00MiB
   System,DUP:             16.00MiB
   Unallocated:               0.00B

/dev/sdb3, ID: 2
   Device size:             1.86TiB
   Device slack:              0.00B
   Unallocated:             1.86TiB

root@sopa:~# btrfs fi usa /data
Overall:
    Device size:           3.71TiB
    Device allocated:           1.86TiB
    Device unallocated:           1.86TiB
    Device missing:             0.00B
    Used:               1.05TiB
    Free (estimated):           2.65TiB    (min: 1.73TiB)
    Data ratio:                  1.00
    Metadata ratio:              2.00
    Global reserve:         512.00MiB    (used: 0.00B)

Data,single: Size:1.84TiB, Used:1.04TiB
   /dev/mapper/sopa-data       1.84TiB

Metadata,single: Size:8.00MiB, Used:0.00B
   /dev/mapper/sopa-data       8.00MiB

Metadata,DUP: Size:6.50GiB, Used:3.00GiB
   /dev/mapper/sopa-data      13.00GiB

System,single: Size:4.00MiB, Used:0.00B
   /dev/mapper/sopa-data       4.00MiB

System,DUP: Size:8.00MiB, Used:224.00KiB
   /dev/mapper/sopa-data      16.00MiB

Unallocated:
   /dev/mapper/sopa-data         0.00B
   /dev/sdb3       1.86TiB


On 14. 01. 20 21:09, Chris Murphy wrote:
> I think it got clipped. And also the MUA is wrapping it and making it
> hard to read. I suggest 'journalctl -k -o short-monotonic' because
> what started the problem might actually be much earlier and there's no
> way to know that without the entire thing. Put that up in a dropbox or
> pastebin or google drive or equivalent. And hopefully a dev will be
> able to figure out why it's hung up. All I can tell from the above is
> that it's hung up on cancelling, which doesn't say much.
>
> _handle_mm_fault is suspicious. On second thought, I suggest doing
> sysrq+t. And then output journalctl -k, and post that. It'll have the
> complete dmesg, the sysrq+w, and +t. That for sure won't post to the
> list, it'll be too long, and the way MUA's wrap it, it's hard to read.
>
> -- Chris Murphy





[Index of Archives]     [Linux Filesystem Development]     [Linux NFS]     [Linux NILFS]     [Linux USB Devel]     [Linux Audio Users]     [Yosemite News]     [Linux Kernel]     [Linux SCSI]

  Powered by Linux