Re: btrfs-progs confusing message
On 04/21/2016 04:02 AM, Austin S. Hemmelgarn wrote: > On 2016-04-20 16:23, Konstantin Svist wrote: >> Pretty much all commands print out the usage message when no device is >> specified: >> >> [root@host ~]# btrfs scrub start >> btrfs scrub start: too few arguments >> usage: btrfs scrub start [-BdqrRf] [-c ioprio_class -n ioprio_classdata] >> | >> ... >> >> However, balance doesn't >> >> [root@host ~]# btrfs balance start >> ERROR: can't access 'start': No such file or directory > > And this is an example of why backwards comparability can be a pain. > The original balance command was 'btrfs filesystem balance', and had > no start, stop, or similar sub-commands. This got changed to the > current incarnation when the support for filters was added. For > backwards compatibility reasons, we decided to still accept balance > with no arguments other than the path as being the same as running > 'btrfs balance start' on that path, and then made the old name an > alias to the new one, with the restriction that you can't pass in > filters through that interface. What is happening here is that > balance is trying to interpret start as a path, not a command, hence > the message about not being able to access 'start'. > So since this is still detected as an error, why not print usage info at this point? -- 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-progs confusing message
Pretty much all commands print out the usage message when no device is specified: [root@host ~]# btrfs scrub start btrfs scrub start: too few arguments usage: btrfs scrub start [-BdqrRf] [-c ioprio_class -n ioprio_classdata] | ... However, balance doesn't [root@host ~]# btrfs balance start ERROR: can't access 'start': No such file or directory -- 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
Re: bedup --defrag freezing
On 08/06/2015 04:10 AM, Austin S Hemmelgarn wrote: On 2015-08-05 17:45, Konstantin Svist wrote: Hi, I've been running btrfs on Fedora for a while now, with bedup --defrag running in a night-time cronjob. Last few runs seem to have gotten stuck, without possibility of even killing the process (kill -9 doesn't work) -- all I could do is hard power cycle. Did something change recently? Is bedup simply too out of date? What should I use to de-duplicate across snapshots instead? Etc.? AFAIK, bedup hasn't been actively developed for quite a while (I'm actually kind of surprised it runs with the newest btrfs-progs). Personally, I'd suggest using duperemove (https://github.com/markfasheh/duperemove) Thanks, good to know. Tried duperemove -- it looks like it builds a database of its own checksums every time it runs... why won't it use BTRFS internal checksums for fast rejection? Would run a LOT faster... -- 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
bedup --defrag freezing
Hi, I've been running btrfs on Fedora for a while now, with bedup --defrag running in a night-time cronjob. Last few runs seem to have gotten stuck, without possibility of even killing the process (kill -9 doesn't work) -- all I could do is hard power cycle. Did something change recently? Is bedup simply too out of date? What should I use to de-duplicate across snapshots instead? Etc.? Thanks, Konstantin # uname -a Linux mireille.svist.net 4.0.8-200.fc21.x86_64 #1 SMP Fri Jul 10 21:09:54 UTC 2015 x86_64 x86_64 x86_64 GNU/Linux # btrfs --version btrfs-progs v4.1 # btrfs fi show Label: none uuid: 5ac56e7d-3d04-4ffa-8160-5a47f46c2939 Total devices 1 FS bytes used 243.43GiB devid1 size 465.76GiB used 318.05GiB path /dev/sda2 btrfs-progs v4.1 # btrfs fi df / Data, single: total=309.01GiB, used=238.24GiB System, single: total=32.00MiB, used=64.00KiB Metadata, single: total=9.01GiB, used=5.19GiB GlobalReserve, single: total=512.00MiB, used=0.00B dmseg attached [0.00] CPU0 microcode updated early to revision 0x1c, date = 2014-07-03 [0.00] Initializing cgroup subsys cpuset [0.00] Initializing cgroup subsys cpu [0.00] Initializing cgroup subsys cpuacct [0.00] Linux version 4.0.8-200.fc21.x86_64 (mockbu...@bkernel02.phx2.fedoraproject.org) (gcc version 4.9.2 20150212 (Red Hat 4.9.2-6) (GCC) ) #1 SMP Fri Jul 10 21:09:54 UTC 2015 [0.00] Command line: BOOT_IMAGE=/main/boot/vmlinuz-4.0.8-200.fc21.x86_64 root=/dev/sda2 ro rootflags=subvol=main vconsole.font=latarcyrheb-sun16 quiet [0.00] e820: BIOS-provided physical RAM map: [0.00] BIOS-e820: [mem 0x-0x0009d7ff] usable [0.00] BIOS-e820: [mem 0x0009d800-0x0009] reserved [0.00] BIOS-e820: [mem 0x000e-0x000f] reserved [0.00] BIOS-e820: [mem 0x0010-0xba14] usable [0.00] BIOS-e820: [mem 0xba15-0xba156fff] ACPI NVS [0.00] BIOS-e820: [mem 0xba157000-0xba94] usable [0.00] BIOS-e820: [mem 0xba95-0xbabedfff] reserved [0.00] BIOS-e820: [mem 0xbabee000-0xcac0afff] usable [0.00] BIOS-e820: [mem 0xcac0b000-0xcb10afff] reserved [0.00] BIOS-e820: [mem 0xcb10b000-0xcb63dfff] usable [0.00] BIOS-e820: [mem 0xcb63e000-0xcb7aafff] ACPI NVS [0.00] BIOS-e820: [mem 0xcb7ab000-0xcbffefff] reserved [0.00] BIOS-e820: [mem 0xcbfff000-0xcbff] usable [0.00] BIOS-e820: [mem 0xcd00-0xcf1f] reserved [0.00] BIOS-e820: [mem 0xf800-0xfbff] reserved [0.00] BIOS-e820: [mem 0xfec0-0xfec00fff] reserved [0.00] BIOS-e820: [mem 0xfed0-0xfed03fff] reserved [0.00] BIOS-e820: [mem 0xfed1c000-0xfed1] reserved [0.00] BIOS-e820: [mem 0xfee0-0xfee00fff] reserved [0.00] BIOS-e820: [mem 0xff00-0x] reserved [0.00] BIOS-e820: [mem 0x0001-0x00022fdf] usable [0.00] NX (Execute Disable) protection: active [0.00] SMBIOS 2.8 present. [0.00] DMI: Notebook P15SM-A/SM1-A/P15SM-A/SM1-A, BIOS 4.6.5 03/27/2014 [0.00] e820: update [mem 0x-0x0fff] usable == reserved [0.00] e820: remove [mem 0x000a-0x000f] usable [0.00] e820: last_pfn = 0x22fe00 max_arch_pfn = 0x4 [0.00] MTRR default type: uncachable [0.00] MTRR fixed ranges enabled: [0.00] 0-9 write-back [0.00] A-B uncachable [0.00] C-C write-protect [0.00] D-E7FFF uncachable [0.00] E8000-F write-protect [0.00] MTRR variable ranges enabled: [0.00] 0 base 00 mask 7E write-back [0.00] 1 base 02 mask 7FE000 write-back [0.00] 2 base 022000 mask 7FF000 write-back [0.00] 3 base 00E000 mask 7FE000 uncachable [0.00] 4 base 00D000 mask 7FF000 uncachable [0.00] 5 base 00CE00 mask 7FFE00 uncachable [0.00] 6 base 00CD00 mask 7FFF00 uncachable [0.00] 7 base 022FE0 mask 7FFFE0 uncachable [0.00] 8 disabled [0.00] 9 disabled [0.00] PAT configuration [0-7]: WB WC UC- UC WB WC UC- UC [0.00] e820: update [mem 0xcd00-0x] usable == reserved [0.00] e820: last_pfn = 0xcc000 max_arch_pfn = 0x4 [0.00] found SMP MP-table at [mem 0x000fd830-0x000fd83f] mapped at [880fd830] [0.00] Base memory trampoline at [88097000] 97000 size 24576 [0.00] Using
corrupt 1, but no other indicators
I'm seeing the following message on every bootup in dmesg /var/log/messages: BTRFS: bdev /dev/sda2 errs: wr 0, rd 0, flush 0, corrupt 1, gen 0 I've tried running scrub and it doesn't indicate any errors occurred Is this normal? Is something actually corrupted? Can I fix it? Details: [root@mireille ~]# uname -a Linux mireille.svist.net 3.19.1-201.fc21.x86_64 #1 SMP Wed Mar 18 04:29:24 UTC 2015 x86_64 x86_64 x86_64 GNU/Linux [root@mireille ~]# btrfs fi show Label: none uuid: 5ac56e7d-3d04-4ffa-8160-5a47f46c2939 Total devices 1 FS bytes used 237.28GiB devid1 size 465.76GiB used 465.76GiB path /dev/sda2 Btrfs v3.18.1 [root@mireille ~]# btrfs --version Btrfs v3.18.1 [root@mireille ~]# btrfs fi show Label: none uuid: 5ac56e7d-3d04-4ffa-8160-5a47f46c2939 Total devices 1 FS bytes used 237.28GiB devid1 size 465.76GiB used 465.76GiB path /dev/sda2 Btrfs v3.18.1 [root@mireille ~]# btrfs fi df / Data, single: total=457.75GiB, used=232.64GiB System, single: total=4.00MiB, used=80.00KiB Metadata, single: total=8.01GiB, used=4.64GiB GlobalReserve, single: total=512.00MiB, used=0.00B dmesg: http://pastebin.com/9B0h4SuA -- 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
Re: btrfs partition remounted read-only
On 07/13/2014 10:13 AM, Chris Murphy wrote: On Jul 4, 2014, at 11:00 AM, Konstantin Svist fry@gmail.com wrote: I have an overnight cron job with /sbin/fstrim -v / /bin/bedup dedup --defrag Probably not related, but these look backwards, why not reverse them? Chris Murphy Thanks, will do that. Anything else useful I could add to the cron job, btw? I was thinking maybe a scrub operation to check for errors.. -- 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 partition remounted read-only
I have an overnight cron job with /sbin/fstrim -v / /bin/bedup dedup --defrag Every once in a while, it causes the FS to be remounted read-only. Problem is pretty intermittent so far (aside from a few kernel revisions a while ago). Please advise. Corresponding bugs: https://bugzilla.kernel.org/show_bug.cgi?id=71311 https://bugzilla.redhat.com/show_bug.cgi?id=1071408 Addtl info: # uname -a Linux mireille.svist.net 3.14.9-200.fc20.x86_64 #1 SMP Thu Jun 26 21:40:51 UTC 2014 x86_64 x86_64 x86_64 GNU/Linux # btrfs --version Btrfs v3.14.2 # btrfs fi show Label: none uuid: 5ac56e7d-3d04-4ffa-8160-5a47f46c2939 Total devices 1 FS bytes used 151.77GiB devid1 size 465.76GiB used 282.02GiB path /dev/sda2 Btrfs v3.14.2 # btrfs fi df / Data, single: total=277.01GiB, used=148.86GiB System, single: total=4.00MiB, used=48.00KiB Metadata, single: total=5.01GiB, used=2.91GiB -- 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
