btrfs device stats /dev/mapper/ext4 SEGV
http://git.kernel.org/?p=linux/kernel/git/mason/btrfs-progs.git I can repeatedly get the following SEGV from running btrfs device stats on a device node for an Ext3/4 filesystem. This happens with the version of the code downloaded from the above GIT repository as well as with an older version. Obviously the command in question is not going to do anything useful when run against a non-BTRFS filesystem, but it should do something other than crash. Program received signal SIGSEGV, Segmentation fault. 0x0045842d in get_fs_info (path=0x7fffce60 /boot, fi_args=0x7fffe6c0, di_ret=0x7fffe6b8) at utils.c:1560 1560fi_args-max_id = fs_devices_mnt-latest_devid; (gdb) bt #0 0x0045842d in get_fs_info (path=0x7fffce60 /boot, fi_args=0x7fffe6c0, di_ret=0x7fffe6b8) at utils.c:1560 #1 0x00408576 in cmd_dev_stats (argc=2, argv=0x7fffec78) at cmds-device.c:331 #2 0x00404177 in handle_command_group (grp=0x684660, argc=2, argv=0x7fffec78) at btrfs.c:154 #3 0x00408830 in cmd_device (argc=3, argv=0x7fffec70) at cmds-device.c:410 #4 0x0040450e in main (argc=3, argv=0x7fffec70) at btrfs.c:296 -- My Main Blog http://etbe.coker.com.au/ My Documents Bloghttp://doc.coker.com.au/ -- 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: error count
On Sat, 10 Aug 2013, Chris Samuel ch...@csamuel.org wrote: On Sun, 4 Aug 2013 03:37:22 PM Bart Noordervliet wrote: a sufficiently up-to-date kernel and btrfs tool will provide the 'btrfs device stats' command, which should give you the info you want. This is what it looks like: chris@quad:~/Downloads/Linux/FileSystems/BtrFS/btrfs-progs$ sudo ./btrfs device stats /srv/DR [/dev/sdb3].write_io_errs 0 [/dev/sdb3].read_io_errs0 [/dev/sdb3].flush_io_errs 0 [/dev/sdb3].corruption_errs 0 [/dev/sdb3].generation_errs 0 Thanks Chris and Bart. Would it be possible to get the man page updated to include a brief description of those errors? The first three are somewhat obvious in meaning (although not obvious in how they would happen) and the fourth is very obvious. But what does generation_errs mean? I'm seeing some on one system. Should I be concerned? If I write a Nagios check which ones should be warnings and which ones errors? Also why does it give the following errors about trying to open /dev/sr0 when using a BTRFS RAID-1 filesystem? Below is for a RAID-1 over /dev/sdb and /dev/sdc. # btrfs device stats /dev/sdb failed to open /dev/sr0: No medium found failed to open /dev/sr0: No medium found [/dev/sdb].write_io_errs 0 [/dev/sdb].read_io_errs0 [/dev/sdb].flush_io_errs 0 [/dev/sdb].corruption_errs 0 [/dev/sdb].generation_errs 0 # btrfs device stats /dev/sdc failed to open /dev/sr0: No medium found failed to open /dev/sr0: No medium found [/dev/sdc].write_io_errs 0 [/dev/sdc].read_io_errs0 [/dev/sdc].flush_io_errs 0 [/dev/sdc].corruption_errs 0 [/dev/sdc].generation_errs 0 Why is it even searching for the other part when only a single device is specified and why can't it give stats without checking /dev/sr0 when checking a single device when it can do so while checking all devices? # btrfs device stats /dev/sdd1 failed to open /dev/sr0: No medium found failed to open /dev/sr0: No medium found [/dev/sdd1].write_io_errs 0 [/dev/sdd1].read_io_errs136 [/dev/sdd1].flush_io_errs 0 [/dev/sdd1].corruption_errs 0 [/dev/sdd1].generation_errs 0 # btrfs device stats /dev/sdd2 failed to open /dev/sr0: No medium found failed to open /dev/sr0: No medium found [/dev/sdd2].write_io_errs 0 [/dev/sdd2].read_io_errs0 [/dev/sdd2].flush_io_errs 0 [/dev/sdd2].corruption_errs 0 [/dev/sdd2].generation_errs 0 # btrfs device stats /mnt/backup/ [/dev/sdd1].write_io_errs 0 [/dev/sdd1].read_io_errs136 [/dev/sdd1].flush_io_errs 0 [/dev/sdd1].corruption_errs 0 [/dev/sdd1].generation_errs 0 [/dev/sdd2].write_io_errs 0 [/dev/sdd2].read_io_errs0 [/dev/sdd2].flush_io_errs 0 [/dev/sdd2].corruption_errs 0 [/dev/sdd2].generation_errs 0 Thanks. -- My Main Blog http://etbe.coker.com.au/ My Documents Bloghttp://doc.coker.com.au/ -- 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
Error relating to /dev/sr0 when calling btrfs fi show /dev/sdxy
Is the error relating to /dev/sr0 relevant to a call to /usr/bin/brtfs? Why does it show the superfluous output? % sudo btrfs fi show /dev/sda3 failed to open /dev/sr0: No medium found Label: 'arch64' uuid: ab6f9133-a2ce-4c92-97ab-35cdc3c2d2a9 Total devices 1 FS bytes used 2.46GB devid 1 size 119.00GB used 5.02GB path /dev/sda3 Btrfs v0.20-rc1-253-g7854c8b -- 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
[GIT PULL] Btrfs
Hi Linus Please pull my for-linus branch: git://git.kernel.org/pub/scm/linux/kernel/git/mason/linux-btrfs.git for-linus These are assorted fixes, mostly from Josef nailing down xfstests runs. Zach also has a long standing fix for problems with readdir wrapping f_pos (or ctx-pos) These patches were spread out over different bases, so I rebased things on top of rc4 and retested overnight. Josef Bacik (6) commits (+82/-52): Btrfs: check to see if root_list is empty before adding it to dead roots (+5/-5) Btrfs: make sure the backref walker catches all refs to our extent (+14/-11) Btrfs: allow splitting of hole em's when dropping extent cache (+40/-22) Btrfs: release both paths before logging dir/changed extents (+2/-3) Btrfs: fix backref walking when we hit a compressed extent (+15/-8) Btrfs: do not offset physical if we're compressed (+6/-3) Liu Bo (2) commits (+12/-5): Btrfs: fix a bug of snapshot-aware defrag to make it work on partial extents (+12/-4) Btrfs: fix extent buffer leak after backref walking (+0/-1) Zach Brown (1) commits (+25/-8): btrfs: don't loop on large offsets in readdir Jie Liu (1) commits (+0/-3): btrfs: fix file truncation if FALLOC_FL_KEEP_SIZE is specified Total: (10) commits (+119/-68) fs/btrfs/backref.c | 48 ++ fs/btrfs/ctree.c | 1 - fs/btrfs/extent_io.c | 9 +--- fs/btrfs/file.c| 62 -- fs/btrfs/inode.c | 52 ++ fs/btrfs/transaction.c | 8 +++ fs/btrfs/transaction.h | 2 +- fs/btrfs/tree-log.c| 5 ++-- 8 files changed, 119 insertions(+), 68 deletions(-) -- 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: error count
On Sat, 10 Aug 2013 07:19:27 PM Russell Coker wrote:
But what does generation_errs mean? I'm seeing some on one system.
Should I be concerned? If I write a Nagios check which ones should be
warnings and which ones errors?
All I know is that ioctl.h says:
BTRFS_DEV_STAT_GENERATION_ERRS, /* an indication that blocks have not
* been written */
Looking at the kernel code that only seems to get incremented during a scrub.
The code that does that says:
} else if (generation != le64_to_cpu(h-generation)) {
sblock-header_error = 1;
sblock-generation_error = 1;
}
The generation there is from the btrfs inode structure, the header says:
/* full 64 bit generation number, struct vfs_inode doesn't have a big
* enough field for this.
*/
u64 generation;
The wiki says:
https://btrfs.wiki.kernel.org/index.php/Glossary
# generation
# An internal counter which updates for each transaction. When a
# metadata block is written (using copy on write), current generation
# is stored in the block, so that blocks which are too new (and hence
# possibly inconsistent) can be identified.
and:
https://btrfs.wiki.kernel.org/index.php/Btrfs_design
# Everything that points to a btree block also stores the generation
# field it expects that block to have. This allows Btrfs to detect
# phantom or misplaced writes on the media.
HTH!
Also why does it give the following errors about trying to open /dev/sr0
when using a BTRFS RAID-1 filesystem? Below is for a RAID-1 over /dev/sdb
and /dev/sdc.
I don't get that here, I'm building btrfs-progs from git at commit
194aa4a1bd6447bb545286d0bcb0b0be8204d79f (July 5th), aka:
btrfs-progs$ git describe --tags
v0.20-rc1-358-g194aa4a
cheers!
Chris
--
Chris Samuel : http://www.csamuel.org/ : Melbourne, VIC
This email may come with a PGP signature as a file. Do not panic.
For more info see: http://en.wikipedia.org/wiki/OpenPGP
signature.asc
Description: This is a digitally signed message part.
Re: btrfs device stats /dev/mapper/ext4 SEGV
On Sat, 10 Aug 2013 07:07:50 PM Russell Coker wrote: I can repeatedly get the following SEGV from running btrfs device stats on a device node for an Ext3/4 filesystem. This happens with the version of the code downloaded from the above GIT repository as well as with an older version. Obviously the command in question is not going to do anything useful when run against a non-BTRFS filesystem, but it should do something other than crash. The code calls btrfs_read_dev_super() on that filesystem, but it looks like the checks are failing to detect it as not btrfs. :-( I can reproduce the crash here too with ext3 and XFS filesystems. -- Chris Samuel : http://www.csamuel.org/ : Melbourne, VIC This email may come with a PGP signature as a file. Do not panic. For more info see: http://en.wikipedia.org/wiki/OpenPGP signature.asc Description: This is a digitally signed message part.
Re: Error relating to /dev/sr0 when calling btrfs fi show /dev/sdxy
On Aug 10, 2013, at 3:59 AM, Mike Audia mike...@gmx.com wrote: Is the error relating to /dev/sr0 relevant to a call to /usr/bin/brtfs? Why does it show the superfluous output? % sudo btrfs fi show /dev/sda3 failed to open /dev/sr0: No medium found I get this on Virtual Box VMs, also with parted. I don't get it with parted or btrfs on baremetal. Chris Murphy-- 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: Question about blocksize, I want to use 16k
On Aug 10, 2013, at 10:17 AM, Chris Murphy li...@colorremedies.com wrote: On Aug 10, 2013, at 9:42 AM, Mike Audia mike...@gmx.com wrote: -s 16k One answer is the drive doesn't expose a 16KB sector. It's basically lying when it reports a 512 byte physical sector, but there isn't anything that can be done about this on the software side. The other answer: http://permalink.gmane.org/gmane.comp.file-systems.btrfs/20746 And also: http://permalink.gmane.org/gmane.comp.file-systems.btrfs/19661 Chris Murphy-- 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: [PATCH 2/2] btrfs: btrfs_rm_device() should zero mirror SB as well
On 8/9/13 9:04 PM, anand jain wrote: btrfs fi show Label: none uuid: e7aae9f0-1aa8-41f5-8fb6-d4d8f80cdb2c Total devices 1 FS bytes used 28.00KiB devid2 size 2.00GiB used 0.00 path /dev/sdc -- WRONG devid1 size 2.00GiB used 20.00MiB path /dev/sdb Ok, now it's findable. Isn't that exactly how this should behave? What is wrong about this? Total devices is still 1. Hm, so it is. But that inconsistency indicates a bug somewhere else, doesn't it? (FWIW the above works for me, w/ the right number of devices shown after removal...) Anyway, I wonder if we've ever resolved the when should we look for backup superblocks? question. Because that would inform decisions about when they should be read, when they must be zeroed, etc. I thought the plan was that backup superblocks should not be read unless we explicitly specify it via mount option or btrfs commandline option. If we must add code to zero all the superblocks on removal to fix something that's still discovering them, that seems to mean backups are still being automatically read. Should they be? What is the design intent for when backup SBs whould be used? Maybe then I could better understand the reason for this change. Thanks, -Eric mount /dev/sdc /btrfs btrfs fi show --kernel Label: none uuid: e7aae9f0-1aa8-41f5-8fb6-d4d8f80cdb2c mounted: /btrfs Group profile: metadata: single data: single Total devices 1 FS bytes used 28.00KiB devid1 size 2.00GiB used 20.00MiB path /dev/sdb Oh good, you could bring it back after a potential administrative error, using a recovery tool (btrfs-select-super)! Isn't that a good thing? Note, here btrfs fi show used the new option --kernel this does not show /dev/sdc though you use it mount. Its all messed up. If user wants to bring back the intentionally deleted disk, then they should rather call btrfs dev add, so that it will take care of integrating the disk back to the FS. recovery tools are for possible recovery from the corruption, delete is not a corruption. Thats an intentional step that user decided to take and the undo for it is 'dev add'. IOWS: what does this change actually fix? Writes zeros to all copies of SB when disk is deleted (before we used to just zero only the first copy). In that way corruption is distinguished from the deleted disk in a fair calculations. Otherwise allowing these things would cost us in terms of support for the administrative error. Which we don't have to encourage. Thanks, Anand -- 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
