Re: Linux 4.14 breaks btrfs filesystems (3 times already)

24.12.17 12:07, Nikolay Borisov пише: > > On 24.12.2017 11:37, Nazar Mokrynskyi wrote: >> Hi folks, >> >> I know this is a bold statement, but this is also exactly what I'm >> experiencing. >> >> 2 filesystems that worked perfectly since July 2015 and one

Linux 4.14 breaks btrfs filesystems (3 times already)

em (SSD > LUKS > BTRFS) and backup filesystem (HDD > LUKS > GPT > BTRFS): compress=lzo,noatime,ssd,subvol=/root compress=lzo,noatime,noexec,noauto Have anyone noticed anything similar (I'm not subscribed to the mailing list)? -- Sincerely, Nazar Mokrynskyi github.com/nazar-pc -- To unsu

Re: Unrecoverable scrub errors

This particular partition was initially created in July 2015. I've added/removed drives a few times when migrating from older to newer hardware, but never used RAID0 or any other RAID level beyond that. Sincerely, Nazar Mokrynskyi github.com/nazar-pc 19.11.17 22:39, Roy Sigurd Karlsbakk пише

Re: Unrecoverable scrub errors

10457856 > > ERROR: errors found in free space cache > found 963515335717 bytes used, error(s) found > total csum bytes: 921699896 > total tree bytes: 20361920512 > total fs tree bytes: 17621073920 > total extent tree bytes: 1629323264 > btree space waste bytes: 3812167723 > file

Re: Unrecoverable scrub errors

19.11.17 07:23, Chris Murphy пише: > On Sat, Nov 18, 2017 at 10:13 PM, Nazar Mokrynskyi <na...@mokrynskyi.com> > wrote: > >> That was eventually useful: >> >> * found some familiar file names (mangled eCryptfs file names from times >> when I used it fo

Re: Unrecoverable scrub errors

19.11.17 06:33, Chris Murphy пише: > On Sat, Nov 18, 2017 at 8:45 PM, Nazar Mokrynskyi <na...@mokrynskyi.com> > wrote: >> 19.11.17 05:19, Chris Murphy пише: >>> On Sat, Nov 18, 2017 at 1:15 AM, Nazar Mokrynskyi <na...@mokrynskyi.com> >>> wrote: &

Re: Unrecoverable scrub errors

19.11.17 05:19, Chris Murphy пише: > On Sat, Nov 18, 2017 at 1:15 AM, Nazar Mokrynskyi <na...@mokrynskyi.com> > wrote: >> I can assure you that drive (it is HDD) is perfectly functional with 0 SMART >> errors or warnings and doesn't have any problems. dmesg is clean in

Re: Unrecoverable scrub errors

there is a chance that data might have being written incorrectly to the drive back then (I didn't run scrub on backup drive for a long time). How can I identify to which files these metadata belong to replace or just remove them (files)? Sincerely, Nazar Mokrynskyi github.com/nazar-pc 18.11.17

Unrecoverable scrub errors

gt;     Total devices 1 FS bytes used 896.20GiB >     devid    1 size 1.00TiB used 920.09GiB path > /dev/mapper/luks-bd5dd3e7-ad80-405f-8dfd-752f2b870f93-part1 > > nazar-pc@nazar-pc ~> sudo btrfs filesystem df /media/Backup > Data, single: total=879.01GiB, used=877.24GiB > Syste

Re: [PATCH 1/2 v2] btrfs-progs: fix btrfs send & receive with -e flag

. I've clarified this in last comment on bugzilla. Sincerely, Nazar Mokrynskyi github.com/nazar-pc Tox: A9D95C9AA5F7A3ED75D83D0292E22ACE84BA40E912185939414475AF28FD2B2A5C8EF5261249 28.04.17 13:03, Lakshmipathi.G пише: > I can take a look. What I'm wondering about is why it fails only in the

Subvolume copy fails with "ERROR: empty stream is not considered valid"

e to Ubuntu's btrfs-progs package. I'm not subscribed to the mailing list, so keep me in copy, please. -- Sincerely, Nazar Mokrynskyi github.com/nazar-pc Tox: A9D95C9AA5F7A3ED75D83D0292E22ACE84BA40E912185939414475AF28FD2B2A5C8EF5261249 -- To unsubscribe from this list: send the line &quo

Re: Major HDD performance degradation on btrfs receive

real cause of performance degradation, then this is something that BTRFS can improve, since I still have 65% of free space on BTRFS partition that receives snapshots and fragmentation in this case seems weird. P.S. I've unsubscribed from mailing list, cc me on answers, please. Sincerely, Nazar Mokr

Re: "bad metadata" not fixed by btrfs repair

I have the same thing with kernel 4.5 and btrfs-progs 4.4. Wrote about it 2 weeks ago and didn't get any answer: https://www.mail-archive.com/linux-btrfs@vger.kernel.org/msg51609.html However, despite those messages everything seems to work fine. Sincerely, Nazar Mokrynskyi github.com/nazar

Re: Major HDD performance degradation on btrfs receive

) I'm not coding C/C++, so my capabilities to improve BTRFS itself are limited, but I'm always trying to find the reason and fix it instead of living with workarounds forever. I'll play with Seekwatcher and optimizing snapshots deletion and will post an update afterwards. Sincerely, Nazar Mokryns

Re: Major HDD performance degradation on btrfs receive

Sounds like a really good idea! I'll try to implement in in my backup tool, but it might take some time to see real benefit from it (or no benefit:)). Sincerely, Nazar Mokrynskyi github.com/nazar-pc Skype: nazar-pc Diaspora:naza...@diaspora.mokrynskyi.com Tox

bad metadata [125501440, 125517824) crossing stripe boundary

found, so what that "bad metadata" things really mean? -- Sincerely, Nazar Mokrynskyi github.com/nazar-pc Skype: nazar-pc Diaspora: naza...@diaspora.mokrynskyi.com Tox: A9D95C9AA5F7A3ED75D83D0292E22ACE84BA40E912185939414475AF28FD2B2A5C8EF5261249 smime.p7s Description: Кріптографічни

Re: Major HDD performance degradation on btrfs receive

ure, but not for Linux filesystems. Saw answer on StackOverlow about fsck, but btrfsck doesn't provide similar output. Also, I can't really run defragmentation anyway since all backups are read-only. Sincerely, Nazar Mokrynskyi github.com/nazar-pc Skype: nazar-pc Diaspora: naza...@diaspora.mokrynskyi.

Re: Major HDD performance degradation on btrfs receive

/BTRFS knowledges are scarce, which is why some assistance here is needed from someone more experienced. Sincerely, Nazar Mokrynskyi github.com/nazar-pc Skype: nazar-pc Diaspora: naza...@diaspora.mokrynskyi.com Tox: A9D95C9AA5F7A3ED75D83D0292E22ACE84BA40E912185939414475AF28FD2B2A5C8EF5261249

Re: Major HDD performance degradation on btrfs receive

can be very busy during a minute or sometimes more, this is not good and basically part or even real reason of initial question. Sincerely, Nazar Mokrynskyi github.com/nazar-pc Skype: nazar-pc Diaspora: naza...@diaspora.mokrynskyi.com

Re: Major HDD performance degradation on btrfs receive

d around 10 seconds to mount it. Sincerely, Nazar Mokrynskyi github.com/nazar-pc Skype: nazar-pc Diaspora:naza...@diaspora.mokrynskyi.com Tox: A9D95C9AA5F7A3ED75D83D0292E22ACE84BA40E912185939414475AF28FD2B2A5C8EF5261249 On 22.02.16 20:58, Nazar Mokrynskyi wrote: On Tue, Feb 16, 2016 at 5:44 AM, Naza

Re: Major HDD performance degradation on btrfs receive

Wow, this is interesting, didn't know it. I'll probably try noatime instead:) Sincerely, Nazar Mokrynskyi github.com/nazar-pc Skype: nazar-pc Diaspora: naza...@diaspora.mokrynskyi.com Tox: A9D95C9AA5F7A3ED75D83D0292E22ACE84BA40E912185939414475AF28FD2B2A5C8EF5261249 On 23.02.16 18:29

Re: Major HDD performance degradation on btrfs receive

But why? I have relatime option, it should not cause changes unless file contents is actually changed if I understand this option correctly. Sincerely, Nazar Mokrynskyi github.com/nazar-pc Skype: nazar-pc Diaspora: naza...@diaspora.mokrynskyi.com Tox

Re: Major HDD performance degradation on btrfs receive

y what I've done here. So now, unless some other atime option is specified, my filesystems are all mounted noatime. =:^) Well, then I'll leave relatime on root fs and noatime on partition with snapshots, thanks. Sincerely, Nazar Mokrynskyi github.com/nazar-pc Skype: nazar-pc Diaspora

Re: Major HDD performance degradation on btrfs receive

On Tue, Feb 16, 2016 at 5:44 AM, Nazar Mokrynskyi <na...@mokrynskyi.com> wrote: > I have 2 SSD with BTRFS filesystem (RAID) on them and several subvolumes. > Each 15 minutes I'm creating read-only snapshot of subvolumes /root, /home > and /web inside /backup. > After this I'm

Re: Major HDD performance degradation on btrfs receive

uotas, there is nothing on this BTRFS partition besides mentioned snapshots. -- Sincerely, Nazar Mokrynskyi github.com/nazar-pc Skype: nazar-pc Diaspora: naza...@diaspora.mokrynskyi.com Tox: A9D95C9AA5F7A3ED75D83D0292E22ACE84BA40E912185939414475AF28FD2B2A5C8EF5261249 smime.p7s Description: Кріптографічний підпис S/MIME

Major HDD performance degradation on btrfs receive

-a0a2-4034-ae55-f8558c0343a8/backup_hdd btrfs compress=lzo,noatime,relatime,noexec 01 -- Sincerely, Nazar Mokrynskyi github.com/nazar-pc Skype: nazar-pc Diaspora: naza...@diaspora.mokrynskyi.com Tox: A9D95C9AA5F7A3ED75D83D0292E22ACE84BA40E912185939414475AF28FD2B2A5C8EF526124

Re: Btrfs wiki account

Thanks Dave, I was finally approved, but with Nazar Mokrynskyi2 username) Any chance to update username to Nazar Mokrynskyi (without 2 at the end)? I've already changed Real name. Tried to reply on admin's email, but it doesn't accept emails actually, so I have to ask here again. Sincerely

Btrfs wiki account

supports wiki. Accounts can be under names Nazar Mokrynskyi and Nazar Mokrynskyi2 (yes, second trial). Sorry for a bit off-topic message. -- Sincerely, Nazar Mokrynskyi github.com/nazar-pc Skype: nazar-pc Diaspora: naza...@diaspora.mokrynskyi.com Tox

Btrfs wiki account

supports wiki. Accounts can be under names Nazar Mokrynskyi and Nazar Mokrynskyi2 (yes, second trial). Sorry for a bit off-topic message. -- Sincerely, Nazar Mokrynskyi github.com/nazar-pc Skype: nazar-pc Diaspora: naza...@diaspora.mokrynskyi.com Tox