Re: btrfs balance enospc
> Does/should a balance imply removal of missing devices (as long as the minimum number of devices are still available)? That's a really good question. As a user I would expect it to balance over remaining devices assuming you still have a complete picture. Doing a device delete missing after a balance should be just some pool metadata updates at that point. Anyway... I solved my problem by moving/deleting files to free up space to the point that balance no longer complained about enospc. I suppose btrfs needs extra working space to do a balance... above and beyond the actual size of the existing data/metadata to be moved? I had a total of three devices, with what appeared to be plenty of space on the two that were to be remaining, but balance/remove was still complaining to be out of disk space. It would be a good idea for some metrics to be calculated upon start of a removal or balance to tell the user "hey you need to free up XXX more bytes in order for this operation to be successful". -- 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 listing is wrong
Root is mounted. This is the same picture after several reboots.
I've actually did some switching things around, drive swaps and some
expansions but it's still oddly displayed.
Label: 'Root' uuid: d71404d4-468e-47d5-8f06-3b65fa7776aa
Total devices 2 FS bytes used 5.81GiB
devid3 size 10.00GiB used 6.78GiB path /dev/sdd6
devid4 size 10.00GiB used 6.78GiB path
/dev/disk/by-uuid/d71404d4-468e-47d5-8f06-3b65fa7776aa
cartman {~} root# ls -al
/dev/disk/by-uuid/d71404d4-468e-47d5-8f06-3b65fa7776aa
lrwxrwxrwx 1 root root 10 Sep 16 16:05
/dev/disk/by-uuid/d71404d4-468e-47d5-8f06-3b65fa7776aa -> ../../sdd6
cartman {~} root# blkid /dev/sdd6
/dev/sdd6: LABEL="Root" UUID="d71404d4-468e-47d5-8f06-3b65fa7776aa"
UUID_SUB="4ab62e9d-e1dc-4cea-92da-b2640fa841d0" TYPE="btrfs"
cartman {~} root# blkid /dev/sdi6
/dev/sdi6: LABEL="Root" UUID="d71404d4-468e-47d5-8f06-3b65fa7776aa"
UUID_SUB="bf76e31c-a49c-4497-83fb-5cb6567b5ad3" TYPE="btrfs"
(dev 4 is really /dev/sdi6)
This was originally a natively created btrfs via mkfs
On 09/13/2014 02:27 AM, Anand Jain wrote:
Hi Mark,
Label: 'Root' uuid: d71404d4-468e-47d5-8f06-3b65fa7776aa
Total devices 2 FS bytes used 7.46GiB
devid1 size 9.31GiB used 8.06GiB path /dev/sdh6
devid3 size 9.31GiB used 8.06GiB path
/dev/disk/by-uuid/d71404d4-468e-47d5-8f06-3b65fa7776aa
I hope this taken when Root is mounted, (just for confirmation),
which means those are read from the btrfs kernel. Not by scanning
the udev.
# ls -al /dev/disk/by-uuid/d71404d4-468e-47d5-8f06-3b65fa7776aa
lrwxrwxrwx 1 root root 10 Sep 11 10:43
/dev/disk/by-uuid/d71404d4-468e-47d5-8f06-3b65fa7776aa -> ../../sdh6
when we read /dev/sdh6 it was devid 1.
When we read /dev/disk/by-uuid/d71404d4-468e-47d5-8f06-3b65fa7776aa
it was devid 3.
But udev also says
/dev/disk/by-uuid/d71404d4-468e-47d5-8f06-3b65fa7776aa
is nothing but a soft link to /dev/sdh6 !!
Very strange ! Can you run blkid and show its output ?
Also by any chance did we do a disk to disk copy ?
devid 3 should really be showing /dev/sde6
A reboot or btrfs kernel module reload might update the stale
and tell the facts.
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
Re: btrfs balance enospc
The smart stats on the disk are fine. The /dev/sdc messages are from me playing around and pulling out the drive. btrfs fi show, shows the drive as missing, yet it's still trying to write to it. Basically my goal is to remove this drive and stick it in another box and I can't get btrfs to move all the data off of it due to enospc. I'm gonna try and move some data off and remove/balance again. On 09/16/14 13:26, Chris Murphy wrote: > Better to use btrfs replace. But sequence wise you should do btrfs device delete missing, which should then effectively do a balance to the newly added device. So while the sequence isn't really correct, that's probably not why you're getting this failure. > > > >> >> >> Sep 16 12:47:12 localhost kernel: BTRFS: bdev /dev/sdc6 errs: wr 2411, >> rd 0, flush 38, corrupt 137167, gen 25 > > Please post results of > smartctl -x /dev/sdc > > I'd expect with Btrfs having problems writing to a device, that there'd be libata messages related to this also. Do you have earlier kernel messages indicating the drive or controller are reporting 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
Re: btrfs balance enospc
316baa365 ]--- Sep 16 12:47:14 localhost kernel: BTRFS: lost page write due to I/O error on /dev/sdc6 Sep 16 12:47:14 localhost kernel: BTRFS: lost page write due to I/O error on /dev/sdc6 Sep 16 12:47:14 localhost kernel: BTRFS: lost page write due to I/O error on /dev/sdc6 On 09/16/14 12:37, Duncan wrote: Mark Murawski posted on Mon, 15 Sep 2014 22:23:47 -0400 as excerpted: I wish i could follow your procedure, but this wasn't an ext conversion. I made this with mkfs for btrfs with kernel circa 3.8ish Good. That possible corner-case is eliminated. then. I had seen nothing indicating it might apply, but better to find that out now than to spend days tearing hair out trying to trace it down, only to discover it's that one already known corner-case! =:^) -- 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 balance enospc
I wish i could follow your procedure, but this wasn't an ext conversion.
I made this with mkfs for btrfs with kernel circa 3.8ish
On 09/15/14 20:08, Duncan wrote:
Chris Murphy posted on Mon, 15 Sep 2014 14:54:57 -0600 as excerpted:
I still get enospc after a balance with a filter, and then a regular
balance:
cartman {~} root# btrfs balance start /
ERROR: error during balancing '/' - No space left on device
Maybe try mount option enospc_debug and retry, see if you get more
information in dmesg.
I'm not sure if a balance in this case wants to create a new data and
metadata chunk (on each device), or if it can start without creating any
chunks. If it wants to create new chunks, it's 1GiB for data, and 256MiB
for metadata. That's 1.256GiB but you only have 1.25GiB unallocated on
each device: size 9.31GiB minus used 8.06GiB.
Another possibility that has hit a few people:
Did you (MM/OP not CM) convert that filesystem from ext* to btrfs? If
so, read on. If not, this doesn't apply so you may skip it.
Assuming such a conversion, did you delete the subvolume containing the
original ext* yet, or not? If not, that may be the problem, because that
subvolume must be left intact in ordered to allow rollback to ext* if
desired. If you know you won't be rolling back, delete the ext* reserved
subvolume as described on the wiki.
Meanwhile, after deleting that subvolume, be sure to complete the defrag
and balance as suggested on the wiki, because failing to do so can lead
to other problems later. Basically, the biggest extent size supported by
btrfs is 1 GiB, the size of a btrfs data chunk, while ext* supports
larger (unlimited size?) extents. Failing to complete the defrag in
particular as suggested can mean large files with extents > 1 GiB in
size, which gives btrfs balance indigestion since it expects to see only
1 GiB or smaller extents. Several folks who converted from ext3/4 have
reported failed balances due to these too large extents, and fixing the
problem later can require manually moving one-by-one all files large
enough to be candidates for the problem (thus files > 1 GiB) out of btrfs
and back in, thus resulting in properly chunk-split extents when the file
is moved back to btrfs. Everyone who has reported this problem so far,
has also reported that the move out and back in process solved the
problem for them, but if there's lots of such files it can be a pain, and
doing the defrag on the formerly ext* files before starting to use the
now btrfs for other things, ESPECIALLY before trying to snapshot affected
subvolumes since that locks the problem in place until those snapshots
are deleted, is definitely preferred. =:^)
--
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 balance enospc
This is with debugging:
cartman {~} root# btrfs balance start /
ERROR: error during balancing '/' - No space left on device
There may be more info in syslog - try dmesg | tail
cartman {~} root#
Sep 15 18:31:47 localhost kernel: BTRFS info (device sdg6): disk space
caching is enabled
Sep 15 18:31:47 localhost kernel: BTRFS info (device sdg6): disk space
caching is enabled
Sep 15 18:31:47 localhost kernel: BTRFS info (device sdi): disk space
caching is enabled
Sep 15 18:31:47 localhost kernel: BTRFS: bdev /dev/sdd7 errs: wr 418589,
rd 444362, flush 11, corrupt 0, gen 0
Sep 15 18:31:47 localhost kernel: r8169 :02:00.0 eth0: link down
Sep 15 18:31:47 localhost kernel: r8169 :02:00.0 eth0: link down
Sep 15 18:31:49 localhost kernel: r8169 :02:00.0 eth0: link up
Sep 15 18:36:05 localhost kernel: BTRFS info (device sdg6): relocating
block group 86631972864 flags 20
Sep 15 18:36:11 localhost kernel: BTRFS info (device sdg6): found 872
extents
Sep 15 18:36:11 localhost kernel: [ cut here ]
Sep 15 18:36:11 localhost kernel: WARNING: CPU: 1 PID: 3763 at
fs/btrfs/extent-tree.c:7273 btrfs_alloc_free_block+0x455/0x4a0()
Sep 15 18:36:11 localhost kernel: BTRFS: block rsv returned -28
Sep 15 18:36:11 localhost kernel: Modules linked in:
Sep 15 18:36:11 localhost kernel: CPU: 1 PID: 3763 Comm: tail Not
tainted 3.16.1 #2
Sep 15 18:36:11 localhost kernel: Hardware name: Gigabyte Technology
Co., Ltd. GA-MA74GM-S2/GA-MA74GM-S2, BIOS F1 04/17/2008
Sep 15 18:36:11 localhost kernel: 819e3610
817e4409 88006ee2fa68
Sep 15 18:36:11 localhost kernel: 8106f6f2 880073fc9e00
88007525b000 1000
Sep 15 18:36:11 localhost kernel: 880072f58280 880074196000
8106f7d5 819f5978
Sep 15 18:36:11 localhost kernel: Call Trace:
Sep 15 18:36:11 localhost kernel: [] ?
dump_stack+0x49/0x6a
Sep 15 18:36:11 localhost kernel: [] ?
warn_slowpath_common+0x82/0xb0
Sep 15 18:36:11 localhost kernel: [] ?
warn_slowpath_fmt+0x45/0x50
Sep 15 18:36:11 localhost kernel: [] ?
___ratelimit+0x94/0x100
Sep 15 18:36:11 localhost kernel: [] ?
btrfs_alloc_free_block+0x455/0x4a0
Sep 15 18:36:11 localhost kernel: [] ?
set_next_entity+0x37/0x80
Sep 15 18:36:11 localhost kernel: [] ?
read_extent_buffer+0xb1/0x110
Sep 15 18:36:11 localhost kernel: [] ?
finish_task_switch+0x49/0xe0
Sep 15 18:36:11 localhost kernel: [] ?
btrfs_copy_root+0xef/0x2a0
Sep 15 18:36:11 localhost kernel: [] ?
create_reloc_root+0x1e3/0x2a0
Sep 15 18:36:11 localhost kernel: [] ?
btrfs_init_reloc_root+0xb8/0xd0
Sep 15 18:36:11 localhost kernel: [] ?
record_root_in_trans+0xaf/0x110
Sep 15 18:36:11 localhost kernel: [] ?
btrfs_record_root_in_trans+0x46/0x80
Sep 15 18:36:11 localhost kernel: [] ?
start_transaction+0x8c/0x4f0
Sep 15 18:36:11 localhost kernel: [] ?
btrfs_dirty_inode+0x58/0xe0
Sep 15 18:36:11 localhost kernel: [] ?
touch_atime+0x152/0x160
Sep 15 18:36:11 localhost kernel: [] ?
generic_file_read_iter+0x545/0x5a0
Sep 15 18:36:11 localhost kernel: [] ?
remove_wait_queue+0x19/0x60
Sep 15 18:36:11 localhost kernel: [] ?
prepare_to_wait+0x24/0x90
Sep 15 18:36:11 localhost kernel: [] ?
new_sync_read+0x73/0xa0
Sep 15 18:36:11 localhost kernel: [] ? vfs_read+0x9e/0x170
Sep 15 18:36:11 localhost kernel: [] ? SyS_read+0x4f/0xd0
Sep 15 18:36:11 localhost kernel: [] ?
system_call_fastpath+0x16/0x1b
Sep 15 18:36:11 localhost kernel: ---[ end trace 8efb39cc34150d60 ]---
Sep 15 18:36:12 localhost kernel: BTRFS info (device sdg6): relocating
block group 86598418432 flags 18
Sep 15 18:36:14 localhost kernel: BTRFS info (device sdg6): found 1 extents
Sep 15 18:36:15 localhost kernel: BTRFS info (device sdg6): relocating
block group 86329982976 flags 20
Sep 15 18:36:49 localhost kernel: BTRFS info (device sdg6): found 55332
extents
Sep 15 18:36:50 localhost kernel: BTRFS info (device sdg6): relocating
block group 86061547520 flags 20
Sep 15 18:37:14 localhost kernel: BTRFS info (device sdg6): found 57486
extents
Sep 15 18:37:14 localhost kernel: use_block_rsv: 2 callbacks suppressed
Sep 15 18:37:14 localhost kernel: [ cut here ]
Sep 15 18:37:14 localhost kernel: WARNING: CPU: 1 PID: 3763 at
fs/btrfs/extent-tree.c:7273 btrfs_alloc_free_block+0x455/0x4a0()
Sep 15 18:37:14 localhost kernel: BTRFS: block rsv returned -28
Sep 15 18:37:14 localhost kernel: Modules linked in:
Sep 15 18:37:14 localhost kernel: CPU: 1 PID: 3763 Comm: tail Tainted: G
W 3.16.1 #2
Sep 15 18:37:14 localhost kernel: Hardware name: Gigabyte Technology
Co., Ltd. GA-MA74GM-S2/GA-MA74GM-S2, BIOS F1 04/17/2008
Sep 15 18:37:14 localhost kernel: 819e3610
817e4409 88006ee2fa68
Sep 15 18:37:14 localhost kernel: 8106f6f2 880073fc9da0
88007525b000 1000
Sep 15 18:37:14 localhost kernel: 880035e393c0 880074196000
8106f7d5 819f5978
Sep 15 18:37:14 localhost
Cannot replace drive
cartman {/etc/rc2.d} root# btrfs fi show /
Label: 'Root' uuid: d71404d4-468e-47d5-8f06-3b65fa7776aa
Total devices 2 FS bytes used 7.43GiB
devid1 size 9.31GiB used 8.37GiB path /dev/sdg6
devid3 size 9.31GiB used 8.37GiB path /dev/sdd6
cartman {/etc/rc2.d} root# btrfs replace start 1 /dev/sdh6 /
cartman {/etc/rc2.d} root#
Sep 15 16:31:36 localhost kernel: BTRFS: dev_replace from /dev/sdg6
(devid 1) to /dev/sdh6 started
Sep 15 16:31:42 localhost kernel: BTRFS: btrfs_scrub_dev(/dev/sdg6, 1,
/dev/sdh6) failed -5
If i do a scrub on /, it will complete with no 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
Re: btrfs balance enospc
btrfs balance start -dusage=86 /
Done, had to relocate 1 out of 13 chunks
cartman {~} root# btrfs fi df /
Data, RAID1: total=7.03GiB, used=7.01GiB
System, RAID1: total=32.00MiB, used=4.00KiB
Metadata, RAID1: total=1.00GiB, used=438.88MiB
unknown, single: total=148.00MiB, used=0.00
What's this 'unknown' section? Maybe this is the problem? How do I get
rid of it?
I still get enospc after a balance with a filter, and then a regular
balance:
cartman {~} root# btrfs balance start /
ERROR: error during balancing '/' - No space left on device
On 09/15/14 13:07, Leonidas Spyropoulos wrote:
On 15/09/14, Mark Murawski wrote:
I should have plenty of space for this operation, but it fails
[...]
This might be useful:
https://btrfs.wiki.kernel.org/index.php/Balance_Filters
Regards,
Leonidas
--
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 balance enospc
I should have plenty of space for this operation, but it fails
cartman {~} root# btrfs filesystem df /
Data, RAID1: total=7.59GiB, used=7.00GiB
System, RAID1: total=32.00MiB, used=4.00KiB
Metadata, RAID1: total=1.00GiB, used=438.45MiB
unknown, single: total=148.00MiB, used=0.00
Filesystem Type Size Used
Avail Use% Mounted on
/dev/disk/by-uuid/d71404d4-468e-47d5-8f06-3b65fa7776aa btrfs 19G 15G
3.1G 84% /
cartman {~} root# btrfs fi show
Label: 'Root' uuid: d71404d4-468e-47d5-8f06-3b65fa7776aa
Total devices 2 FS bytes used 7.43GiB
devid1 size 9.31GiB used 8.06GiB path
/dev/disk/by-uuid/d71404d4-468e-47d5-8f06-3b65fa7776aa
devid3 size 9.31GiB used 8.06GiB path /dev/sdd6
Label: 'Storage' uuid: 179749c1-1bfb-4f28-9c69-72126c96cdef
Total devices 8 FS bytes used 1.83TiB
devid1 size 149.05GiB used 149.04GiB path /dev/sde
devid2 size 149.05GiB used 149.05GiB path /dev/sdh
devid3 size 465.76GiB used 465.76GiB path /dev/sdc
devid4 size 465.76GiB used 461.70GiB path /dev/sdf
devid5 size 465.76GiB used 461.00GiB path /dev/sda
devid6 size 465.76GiB used 461.00GiB path /dev/sdb
devid7 size 920.34GiB used 843.00GiB path /dev/sdg7
devid9 size 1.81TiB used 755.00GiB path /dev/sdd7
Btrfs v3.16
cartman {~} root# btrfs balance start /
ERROR: error during balancing '/' - No space left on device
There may be more info in syslog - try dmesg | tail
Sep 13 16:35:42 localhost kernel: BTRFS info (device sdg6): found 33544
extents
Sep 13 16:35:51 localhost kernel: BTRFS info (device sdg6): found 33541
extents
Sep 13 16:35:52 localhost kernel: BTRFS info (device sdg6): relocating
block group 80153214976 flags 18
Sep 13 16:35:53 localhost kernel: BTRFS info (device sdg6): found 1 extents
Sep 13 16:35:54 localhost kernel: BTRFS info (device sdg6): relocating
block group 79680700416 flags 17
Sep 13 16:36:03 localhost kernel: BTRFS info (device sdg6): found 32545
extents
Sep 13 16:36:09 localhost kernel: BTRFS info (device sdg6): found 32545
extents
Sep 13 16:36:10 localhost kernel: BTRFS info (device sdg6): relocating
block group 79412264960 flags 20
Sep 13 16:36:12 localhost kernel: BTRFS info (device sdg6): found 1114
extents
Sep 13 16:36:13 localhost kernel: BTRFS info (device sdg6): relocating
block group 79143829504 flags 20
Sep 13 16:36:37 localhost kernel: BTRFS info (device sdg6): found 59076
extents
Sep 13 16:36:38 localhost kernel: BTRFS info (device sdg6): relocating
block group 78875394048 flags 20
Sep 13 16:37:01 localhost kernel: BTRFS info (device sdg6): found 59268
extents
Sep 13 16:37:02 localhost kernel: BTRFS info (device sdg6): 6 enospc
errors during balance
--
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 listing is wrong
Label: 'Root' uuid: d71404d4-468e-47d5-8f06-3b65fa7776aa Total devices 2 FS bytes used 7.46GiB devid1 size 9.31GiB used 8.06GiB path /dev/sdh6 devid3 size 9.31GiB used 8.06GiB path /dev/disk/by-uuid/d71404d4-468e-47d5-8f06-3b65fa7776aa # ls -al /dev/disk/by-uuid/d71404d4-468e-47d5-8f06-3b65fa7776aa lrwxrwxrwx 1 root root 10 Sep 11 10:43 /dev/disk/by-uuid/d71404d4-468e-47d5-8f06-3b65fa7776aa -> ../../sdh6 devid 3 should really be showing /dev/sde6 -- 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: Task Hang
S... was this a help to anyone?
On 03/06/14 11:48, Mark Murawski wrote:
Not the same problem, but I do have a lockup with another situation.
I tried adding some new devices... but accidentally screwed up the
syntax (not sure if this had anything to do with the lockup)
btrfs device add / /dev/sdb
probe of / failed, cannot detect existing filesystem.
Use the -f option to force overwrite.
office-backup {~} root# btrfs device add /dev/sdb /dev/sdd
ERROR: error adding the device '/dev/sdb' - Inappropriate ioctl for device
D 1772 [btrfs-transacti]
D 6530 [btrfs-submit-2]
D 7301 /usr/bin/perl /usr/share/backuppc/bin/BackupPC_link demo3
D 7471 fdisk /dev/sdb
D 7523 [btrfs-submit-2]
D 7526 -bash
D 7527 -bash
D 28611 /usr/bin/perl /usr/share/backuppc/bin/BackupPC_trashClean
Attached is output from w to sysrq
On 03/04/2014 09:58 AM, Josef Bacik wrote:
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On 03/04/2014 09:19 AM, Mark Murawski wrote:
I have btrfs as the fs for a backuppc box. updatedb was running at
the same time as a massive rsync.
Mar 4 08:31:00 office-backup kernel: INFO: task
updatedb.mlocat:903 blocked for more than 120 seconds. Mar 4
08:31:00 office-backup kernel: Not tainted 3.13.2 #3 Mar 4
08:31:00 office-backup kernel: "echo 0 >
/proc/sys/kernel/hung_task_timeout_secs" disables this message. Mar
4 08:31:00 office-backup kernel: updatedb.mlocat D
0 903899 0x Mar 4 08:31:00
office-backup kernel: 88007cad6270 0086
88007c0ee900 4000 Mar 4 08:31:00 office-backup
kernel: 88005a705fd8 88007cad6270 00541a6be000
88007b9ac000 Mar 4 08:31:00 office-backup kernel:
88001ad2ef68 880001f97000 8800452d4480
812c3e5c Mar 4 08:31:00 office-backup kernel: Call Trace:
Mar 4 08:31:00 office-backup kernel: [] ?
btrfs_map_bio+0x4ac/0x5a0 Mar 4 08:31:00 office-backup kernel:
[] ? repair_io_failure+0x210/0x210 Mar 4
08:31:00 office-backup kernel: [] ?
__lock_page+0x70/0x70 Mar 4 08:31:00 office-backup kernel:
[] ? io_schedule+0x87/0xd0 Mar 4 08:31:00
office-backup kernel: [] ?
sleep_on_page+0x9/0x10 Mar 4 08:31:00 office-backup kernel:
[] ? __wait_on_bit+0x52/0x80 Mar 4 08:31:00
office-backup kernel: [] ?
btree_submit_bio_hook+0xe1/0x110 Mar 4 08:31:00 office-backup
kernel: [] ? wait_on_page_bit+0x73/0x80 Mar 4
08:31:00 office-backup kernel: [] ?
wake_atomic_t_function+0x30/0x30 Mar 4 08:31:00 office-backup
kernel: [] ?
read_extent_buffer_pages+0x2aa/0x2e0 Mar 4 08:31:00 office-backup
kernel: [] ? add_to_page_cache_lru+0x25/0x40 Mar
4 08:31:00 office-backup kernel: [] ?
radix_tree_insert+0x91/0x250 Mar 4 08:31:00 office-backup kernel:
[] ? verify_parent_transid+0x170/0x170 Mar 4
08:31:00 office-backup kernel: [] ?
btree_read_extent_buffer_pages.constprop.126+0xa9/0x110 Mar 4
08:31:00 office-backup kernel: [] ?
read_tree_block+0x33/0x60 Mar 4 08:31:00 office-backup kernel:
[] ? read_block_for_search.isra.45+0x18c/0x3b0
Mar 4 08:31:00 office-backup kernel: [] ?
comp_keys+0x27/0x30 Mar 4 08:31:00 office-backup kernel:
[] ? btrfs_search_slot+0x41c/0x920 Mar 4
08:31:00 office-backup kernel: [] ?
btrfs_get_token_16+0x61/0xf0 Mar 4 08:31:00 office-backup kernel:
[] ? btrfs_lookup_inode+0x25/0xa0 Mar 4 08:31:00
office-backup kernel: [] ?
kmem_cache_alloc+0xc0/0xe0 Mar 4 08:31:00 office-backup kernel:
[] ? btrfs_iget+0x103/0x520 Mar 4 08:31:00
office-backup kernel: [] ?
btrfs_lookup_dir_item+0x9f/0xd0 Mar 4 08:31:00 office-backup
kernel: [] ? btrfs_lookup_dentry+0x3db/0x4c0 Mar
4 08:31:00 office-backup kernel: [] ?
btrfs_lookup+0x9/0x20 Mar 4 08:31:00 office-backup kernel:
[] ? lookup_real+0x14/0x50 Mar 4 08:31:00
office-backup kernel: [] ?
__lookup_hash+0x32/0x50 Mar 4 08:31:00 office-backup kernel:
[] ? lookup_slow+0x48/0xc0 Mar 4 08:31:00
office-backup kernel: [] ?
path_lookupat+0x711/0x760 Mar 4 08:31:00 office-backup kernel:
[] ? filename_lookup+0x2f/0xd0 Mar 4 08:31:00
office-backup kernel: [] ?
getname_flags+0xb7/0x190 Mar 4 08:31:00 office-backup kernel:
[] ? user_path_at_empty+0x5e/0xb0 Mar 4 08:31:00
office-backup kernel: [] ?
cp_new_stat+0x10d/0x120 Mar 4 08:31:00 office-backup kernel:
[] ? vfs_fstatat+0x41/0x90 Mar 4 08:31:00
office-backup kernel: [] ?
SyS_newlstat+0x12/0x30 Mar 4 08:31:00 office-backup kernel:
[] ? system_call_fastpath+0x16/0x1b Mar 4
08:55:01 office-backup kernel: INFO: task updatedb.mlocat:903
blocked for more than 120 seconds. Mar 4 08:55:01 office-backup
kernel: Not tainted 3.13.2 #3 Mar 4 08:55:01 office-backup
kernel: "echo 0 > /proc/sys/kernel/hung_task_timeout_secs" disables
this message. Mar 4 08:55:01 office-backup kernel: updatedb.mlocat
D 0 903899 0x Mar 4 08:55:01
office-backup kernel: 88007cad6270 0086
88007bb020d0 4000 Mar 4 08:55:01 office-backup
kernel: 88005a705fd8 88007cad6270 0055b6aee000
fff
Re: Task Hang
Not the same problem, but I do have a lockup with another situation.
I tried adding some new devices... but accidentally screwed up the
syntax (not sure if this had anything to do with the lockup)
btrfs device add / /dev/sdb
probe of / failed, cannot detect existing filesystem.
Use the -f option to force overwrite.
office-backup {~} root# btrfs device add /dev/sdb /dev/sdd
ERROR: error adding the device '/dev/sdb' - Inappropriate ioctl for device
D 1772 [btrfs-transacti]
D 6530 [btrfs-submit-2]
D 7301 /usr/bin/perl /usr/share/backuppc/bin/BackupPC_link demo3
D 7471 fdisk /dev/sdb
D 7523 [btrfs-submit-2]
D 7526 -bash
D 7527 -bash
D 28611 /usr/bin/perl /usr/share/backuppc/bin/BackupPC_trashClean
Attached is output from w to sysrq
On 03/04/2014 09:58 AM, Josef Bacik wrote:
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On 03/04/2014 09:19 AM, Mark Murawski wrote:
I have btrfs as the fs for a backuppc box. updatedb was running at
the same time as a massive rsync.
Mar 4 08:31:00 office-backup kernel: INFO: task
updatedb.mlocat:903 blocked for more than 120 seconds. Mar 4
08:31:00 office-backup kernel: Not tainted 3.13.2 #3 Mar 4
08:31:00 office-backup kernel: "echo 0 >
/proc/sys/kernel/hung_task_timeout_secs" disables this message. Mar
4 08:31:00 office-backup kernel: updatedb.mlocat D
0 903899 0x Mar 4 08:31:00
office-backup kernel: 88007cad6270 0086
88007c0ee900 4000 Mar 4 08:31:00 office-backup
kernel: 88005a705fd8 88007cad6270 00541a6be000
88007b9ac000 Mar 4 08:31:00 office-backup kernel:
88001ad2ef68 880001f97000 8800452d4480
812c3e5c Mar 4 08:31:00 office-backup kernel: Call Trace:
Mar 4 08:31:00 office-backup kernel: [] ?
btrfs_map_bio+0x4ac/0x5a0 Mar 4 08:31:00 office-backup kernel:
[] ? repair_io_failure+0x210/0x210 Mar 4
08:31:00 office-backup kernel: [] ?
__lock_page+0x70/0x70 Mar 4 08:31:00 office-backup kernel:
[] ? io_schedule+0x87/0xd0 Mar 4 08:31:00
office-backup kernel: [] ?
sleep_on_page+0x9/0x10 Mar 4 08:31:00 office-backup kernel:
[] ? __wait_on_bit+0x52/0x80 Mar 4 08:31:00
office-backup kernel: [] ?
btree_submit_bio_hook+0xe1/0x110 Mar 4 08:31:00 office-backup
kernel: [] ? wait_on_page_bit+0x73/0x80 Mar 4
08:31:00 office-backup kernel: [] ?
wake_atomic_t_function+0x30/0x30 Mar 4 08:31:00 office-backup
kernel: [] ?
read_extent_buffer_pages+0x2aa/0x2e0 Mar 4 08:31:00 office-backup
kernel: [] ? add_to_page_cache_lru+0x25/0x40 Mar
4 08:31:00 office-backup kernel: [] ?
radix_tree_insert+0x91/0x250 Mar 4 08:31:00 office-backup kernel:
[] ? verify_parent_transid+0x170/0x170 Mar 4
08:31:00 office-backup kernel: [] ?
btree_read_extent_buffer_pages.constprop.126+0xa9/0x110 Mar 4
08:31:00 office-backup kernel: [] ?
read_tree_block+0x33/0x60 Mar 4 08:31:00 office-backup kernel:
[] ? read_block_for_search.isra.45+0x18c/0x3b0
Mar 4 08:31:00 office-backup kernel: [] ?
comp_keys+0x27/0x30 Mar 4 08:31:00 office-backup kernel:
[] ? btrfs_search_slot+0x41c/0x920 Mar 4
08:31:00 office-backup kernel: [] ?
btrfs_get_token_16+0x61/0xf0 Mar 4 08:31:00 office-backup kernel:
[] ? btrfs_lookup_inode+0x25/0xa0 Mar 4 08:31:00
office-backup kernel: [] ?
kmem_cache_alloc+0xc0/0xe0 Mar 4 08:31:00 office-backup kernel:
[] ? btrfs_iget+0x103/0x520 Mar 4 08:31:00
office-backup kernel: [] ?
btrfs_lookup_dir_item+0x9f/0xd0 Mar 4 08:31:00 office-backup
kernel: [] ? btrfs_lookup_dentry+0x3db/0x4c0 Mar
4 08:31:00 office-backup kernel: [] ?
btrfs_lookup+0x9/0x20 Mar 4 08:31:00 office-backup kernel:
[] ? lookup_real+0x14/0x50 Mar 4 08:31:00
office-backup kernel: [] ?
__lookup_hash+0x32/0x50 Mar 4 08:31:00 office-backup kernel:
[] ? lookup_slow+0x48/0xc0 Mar 4 08:31:00
office-backup kernel: [] ?
path_lookupat+0x711/0x760 Mar 4 08:31:00 office-backup kernel:
[] ? filename_lookup+0x2f/0xd0 Mar 4 08:31:00
office-backup kernel: [] ?
getname_flags+0xb7/0x190 Mar 4 08:31:00 office-backup kernel:
[] ? user_path_at_empty+0x5e/0xb0 Mar 4 08:31:00
office-backup kernel: [] ?
cp_new_stat+0x10d/0x120 Mar 4 08:31:00 office-backup kernel:
[] ? vfs_fstatat+0x41/0x90 Mar 4 08:31:00
office-backup kernel: [] ?
SyS_newlstat+0x12/0x30 Mar 4 08:31:00 office-backup kernel:
[] ? system_call_fastpath+0x16/0x1b Mar 4
08:55:01 office-backup kernel: INFO: task updatedb.mlocat:903
blocked for more than 120 seconds. Mar 4 08:55:01 office-backup
kernel: Not tainted 3.13.2 #3 Mar 4 08:55:01 office-backup
kernel: "echo 0 > /proc/sys/kernel/hung_task_timeout_secs" disables
this message. Mar 4 08:55:01 office-backup kernel: updatedb.mlocat
D 0 903899 0x Mar 4 08:55:01
office-backup kernel: 88007cad6270 0086
88007bb020d0 4000 Mar 4 08:55:01 office-backup
kernel: 88005a705fd8 88007cad6270 0055b6aee000
88007b9ac000 Mar 4 08:55:01 office-backup kernel:
8800048282
Task Hang
I have btrfs as the fs for a backuppc box. updatedb was running at the same time as a massive rsync. Mar 4 08:31:00 office-backup kernel: INFO: task updatedb.mlocat:903 blocked for more than 120 seconds. Mar 4 08:31:00 office-backup kernel: Not tainted 3.13.2 #3 Mar 4 08:31:00 office-backup kernel: "echo 0 > /proc/sys/kernel/hung_task_timeout_secs" disables this message. Mar 4 08:31:00 office-backup kernel: updatedb.mlocat D 0 903899 0x Mar 4 08:31:00 office-backup kernel: 88007cad6270 0086 88007c0ee900 4000 Mar 4 08:31:00 office-backup kernel: 88005a705fd8 88007cad6270 00541a6be000 88007b9ac000 Mar 4 08:31:00 office-backup kernel: 88001ad2ef68 880001f97000 8800452d4480 812c3e5c Mar 4 08:31:00 office-backup kernel: Call Trace: Mar 4 08:31:00 office-backup kernel: [] ? btrfs_map_bio+0x4ac/0x5a0 Mar 4 08:31:00 office-backup kernel: [] ? repair_io_failure+0x210/0x210 Mar 4 08:31:00 office-backup kernel: [] ? __lock_page+0x70/0x70 Mar 4 08:31:00 office-backup kernel: [] ? io_schedule+0x87/0xd0 Mar 4 08:31:00 office-backup kernel: [] ? sleep_on_page+0x9/0x10 Mar 4 08:31:00 office-backup kernel: [] ? __wait_on_bit+0x52/0x80 Mar 4 08:31:00 office-backup kernel: [] ? btree_submit_bio_hook+0xe1/0x110 Mar 4 08:31:00 office-backup kernel: [] ? wait_on_page_bit+0x73/0x80 Mar 4 08:31:00 office-backup kernel: [] ? wake_atomic_t_function+0x30/0x30 Mar 4 08:31:00 office-backup kernel: [] ? read_extent_buffer_pages+0x2aa/0x2e0 Mar 4 08:31:00 office-backup kernel: [] ? add_to_page_cache_lru+0x25/0x40 Mar 4 08:31:00 office-backup kernel: [] ? radix_tree_insert+0x91/0x250 Mar 4 08:31:00 office-backup kernel: [] ? verify_parent_transid+0x170/0x170 Mar 4 08:31:00 office-backup kernel: [] ? btree_read_extent_buffer_pages.constprop.126+0xa9/0x110 Mar 4 08:31:00 office-backup kernel: [] ? read_tree_block+0x33/0x60 Mar 4 08:31:00 office-backup kernel: [] ? read_block_for_search.isra.45+0x18c/0x3b0 Mar 4 08:31:00 office-backup kernel: [] ? comp_keys+0x27/0x30 Mar 4 08:31:00 office-backup kernel: [] ? btrfs_search_slot+0x41c/0x920 Mar 4 08:31:00 office-backup kernel: [] ? btrfs_get_token_16+0x61/0xf0 Mar 4 08:31:00 office-backup kernel: [] ? btrfs_lookup_inode+0x25/0xa0 Mar 4 08:31:00 office-backup kernel: [] ? kmem_cache_alloc+0xc0/0xe0 Mar 4 08:31:00 office-backup kernel: [] ? btrfs_iget+0x103/0x520 Mar 4 08:31:00 office-backup kernel: [] ? btrfs_lookup_dir_item+0x9f/0xd0 Mar 4 08:31:00 office-backup kernel: [] ? btrfs_lookup_dentry+0x3db/0x4c0 Mar 4 08:31:00 office-backup kernel: [] ? btrfs_lookup+0x9/0x20 Mar 4 08:31:00 office-backup kernel: [] ? lookup_real+0x14/0x50 Mar 4 08:31:00 office-backup kernel: [] ? __lookup_hash+0x32/0x50 Mar 4 08:31:00 office-backup kernel: [] ? lookup_slow+0x48/0xc0 Mar 4 08:31:00 office-backup kernel: [] ? path_lookupat+0x711/0x760 Mar 4 08:31:00 office-backup kernel: [] ? filename_lookup+0x2f/0xd0 Mar 4 08:31:00 office-backup kernel: [] ? getname_flags+0xb7/0x190 Mar 4 08:31:00 office-backup kernel: [] ? user_path_at_empty+0x5e/0xb0 Mar 4 08:31:00 office-backup kernel: [] ? cp_new_stat+0x10d/0x120 Mar 4 08:31:00 office-backup kernel: [] ? vfs_fstatat+0x41/0x90 Mar 4 08:31:00 office-backup kernel: [] ? SyS_newlstat+0x12/0x30 Mar 4 08:31:00 office-backup kernel: [] ? system_call_fastpath+0x16/0x1b Mar 4 08:55:01 office-backup kernel: INFO: task updatedb.mlocat:903 blocked for more than 120 seconds. Mar 4 08:55:01 office-backup kernel: Not tainted 3.13.2 #3 Mar 4 08:55:01 office-backup kernel: "echo 0 > /proc/sys/kernel/hung_task_timeout_secs" disables this message. Mar 4 08:55:01 office-backup kernel: updatedb.mlocat D 0 903899 0x Mar 4 08:55:01 office-backup kernel: 88007cad6270 0086 88007bb020d0 4000 Mar 4 08:55:01 office-backup kernel: 88005a705fd8 88007cad6270 0055b6aee000 88007b9ac000 Mar 4 08:55:01 office-backup kernel: 8800048282e8 880076f8 8800272a09c0 812c3e5c Mar 4 08:55:01 office-backup kernel: Call Trace: Mar 4 08:55:01 office-backup kernel: [] ? btrfs_map_bio+0x4ac/0x5a0 Mar 4 08:55:01 office-backup kernel: [] ? repair_io_failure+0x210/0x210 Mar 4 08:55:01 office-backup kernel: [] ? __lock_page+0x70/0x70 Mar 4 08:55:01 office-backup kernel: [] ? io_schedule+0x87/0xd0 Mar 4 08:55:01 office-backup kernel: [] ? sleep_on_page+0x9/0x10 Mar 4 08:55:01 office-backup kernel: [] ? __wait_on_bit+0x52/0x80 Mar 4 08:55:01 office-backup kernel: [] ? btree_submit_bio_hook+0xe1/0x110 Mar 4 08:55:01 office-backup kernel: [] ? wait_on_page_bit+0x73/0x80 Mar 4 08:55:01 office-backup kernel: [] ? wake_atomic_t_function+0x30/0x30 Mar 4 08:55:01 office-backup kernel: [] ? read_extent_buffer_pages+0x2aa/0x2e0 Mar 4 08:55:01 office-backup kernel: [] ? add_to_page_cac
BUG
With this array I have to mount -o degraded, even though all devices are
present.
Linux cartman 3.9.0 #1 SMP PREEMPT Fri May 3 22:02:21 EDT 2013 x86_64
GNU/Linux
btrfs-tools
git://git.kernel.org/pub/scm/linux/kernel/git/mason/btrfs-progs.git *
master 7854c8b
When I try and mount without degraded, I get this:
btrfs: failed to read chunk tree on sdh
btrfs: open_ctree failed
Mounting -o degraded, I get this:
cartman {~} root# btrfs filesystem show
Label: none uuid: d71404d4-468e-47d5-8f06-3b65fa7776aa
Total devices 2 FS bytes used 7.01GB
devid1 size 9.31GB used 8.35GB path /dev/sdg6
devid3 size 9.31GB used 8.34GB path /dev/sdc6
Label: none uuid: b142f575-df1c-4a57-8846-a43b979e2e09
Total devices 8 FS bytes used 1.79TB
devid4 size 149.05GB used 7.00GB path /dev/sdh
devid6 size 920.34GB used 495.00GB path /dev/sdg7
devid8 size 1.36TB used 1.21TB path /dev/sdf
devid2 size 465.76GB used 303.00GB path /dev/sde
devid3 size 149.05GB used 6.00GB path /dev/sdd
devid5 size 920.34GB used 745.03GB path /dev/sdc7
devid9 size 465.76GB used 303.00GB path /dev/sdb
devid7 size 1.36TB used 1.21TB path /dev/sda
Btrfs v0.20-rc1-253-g7854c8b
Tried to fix up /dev/sdh...
cartman {~} root# btrfs device delete /dev/sdh /storage
btrfs: bdev /dev/sda errs: wr 0, rd 0, flush 0, corrupt 4733368, gen 0
btrfs: relocating block group 4787944816640 flags 17
btrfs: free space inode generation (0) did not match free space cache
generation (19517)
btrfs: free space inode generation (0) did not match free space cache
generation (19519)
btrfs: free space inode generation (0) did not match free space cache
generation (19519)
btrfs: free space inode generation (0) did not match free space cache
generation (8540)
btrfs: free space inode generation (0) did not match free space cache
generation (9080)
btrfs: free space inode generation (0) did not match free space cache
generation (9143)
btrfs: free space inode generation (0) did not match free space cache
generation (28604)
btrfs: free space inode generation (0) did not match free space cache
generation (28604)
btrfs: free space inode generation (0) did not match free space cache
generation (30096)
btrfs: free space inode generation (0) did not match free space cache
generation (28551)
btrfs: free space inode generation (0) did not match free space cache
generation (30191)
btrfs: free space inode generation (0) did not match free space cache
generation (28613)
btrfs: free space inode generation (0) did not match free space cache
generation (30191)
btrfs: free space inode generation (0) did not match free space cache
generation (30191)
btrfs: free space inode generation (0) did not match free space cache
generation (19382)
btrfs: free space inode generation (0) did not match free space cache
generation (28867)
btrfs: free space inode generation (0) did not match free space cache
generation (28623)
btrfs: free space inode generation (0) did not match free space cache
generation (28623)
btrfs: free space inode generation (0) did not match free space cache
generation (19382)
btrfs: free space inode generation (0) did not match free space cache
generation (19387)
btrfs: free space inode generation (0) did not match free space cache
generation (19387)
btrfs: free space inode generation (0) did not match free space cache
generation (19387)
btrfs: free space inode generation (0) did not match free space cache
generation (19387)
btrfs: free space inode generation (0) did not match free space cache
generation (19387)
Jun 10 05:20:21 localhost kernel: btrfs: found 31 extents
Jun 10 05:20:30 localhost kernel: btrfs: found 31 extents
Jun 10 05:20:30 localhost kernel: btrfs: relocating block group
4784723591168 flags 17
Jun 10 05:21:00 localhost kernel: btrfs: found 33 extents
Jun 10 05:21:11 localhost kernel: btrfs: found 33 extents
Jun 10 05:21:11 localhost kernel: btrfs: relocating block group
4781502365696 flags 17
Jun 10 05:21:40 localhost kernel: btrfs: found 29 extents
Jun 10 05:21:49 localhost kernel: btrfs: found 29 extents
Jun 10 05:21:49 localhost kernel: btrfs: relocating block group
4778281140224 flags 17
Jun 10 05:22:19 localhost kernel: btrfs: found 65 extents
Jun 10 05:22:32 localhost kernel: btrfs: found 65 extents
Jun 10 05:22:33 localhost kernel: btrfs: relocating block group
4775059914752 flags 17
Jun 10 05:23:04 localhost kernel: btrfs: found 20 extents
Jun 10 05:23:11 localhost kernel: btrfs: found 20 extents
Jun 10 05:23:13 localhost kernel: btrfs: relocating block group
4771838689280 flags 17
Jun 10 05:23:41 localhost kernel: btrfs: found 27 extents
Jun 10 05:23:48 localhost kernel: btrfs: found 27 extents
Jun 10 05:23:49 localhost kernel: btrfs: relocating block group
4768617463808 flags 17
Jun 10 05:24:17 localhost kernel: btrfs: found 14 extents
Jun 10 05:24:24 localhost kernel: btrfs: found 14 exte
btrfs device delete missing problem
Using the latest mason git (and kernel 3.3.4)
stan {~} root# btrfs filesystem show
Label: none uuid: d71404d4-468e-47d5-8f06-3b65fa7776aa
Total devices 2 FS bytes used 7.09GB
devid2 size 9.31GB used 9.09GB path /dev/sdd6
devid1 size 9.31GB used 9.09GB path /dev/sdg6
Label: none uuid: b142f575-df1c-4a57-8846-a43b979e2e09
Total devices 9 FS bytes used 1.35TB
devid8 size 1.36TB used 1.07TB path /dev/sda
devid7 size 1.36TB used 1.07TB path /dev/sde
devid2 size 465.76GB used 134.00GB path /dev/sdb
devid4 size 149.05GB used 0.00 path /dev/sdc
devid9 size 465.76GB used 161.00GB path /dev/sdf
devid3 size 149.05GB used 0.00 path /dev/sdh
devid5 size 920.34GB used 616.03GB path /dev/sdd7
devid6 size 920.34GB used 616.03GB path /dev/sdg7
*** Some devices missing
stan {~} root# btrfs device delete missing /storage
May 5 05:28:40 stan kernel: btrfs: relocating block group 0 flags 2
stan {~} root#
stan {~} root# btrfs filesystem show
Label: none uuid: d71404d4-468e-47d5-8f06-3b65fa7776aa
Total devices 2 FS bytes used 7.09GB
devid1 size 9.31GB used 9.09GB path /dev/sdg6
devid2 size 9.31GB used 9.09GB path /dev/sdd6
Label: none uuid: b142f575-df1c-4a57-8846-a43b979e2e09
Total devices 9 FS bytes used 1.35TB
devid3 size 149.05GB used 0.00 path /dev/sdh
devid6 size 920.34GB used 616.03GB path /dev/sdg7
devid9 size 465.76GB used 161.00GB path /dev/sdf
devid7 size 1.36TB used 1.07TB path /dev/sde
devid5 size 920.34GB used 616.03GB path /dev/sdd7
devid4 size 149.05GB used 0.00 path /dev/sdc
devid2 size 465.76GB used 134.00GB path /dev/sdb
devid8 size 1.36TB used 1.07TB path /dev/sda
*** Some devices missing
--
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 scrub BUG: unable to handle kernel NULL pointer dereference
I think I have some failing hard drives, they are disconnected for now.
stan {~} root# btrfs filesystem show
Label: none uuid: d71404d4-468e-47d5-8f06-3b65fa7776aa
Total devices 2 FS bytes used 6.27GB
devid1 size 9.31GB used 8.16GB path /dev/sde6
*** Some devices missing
Label: none uuid: b142f575-df1c-4a57-8846-a43b979e2e09
Total devices 8 FS bytes used 1.35TB
devid3 size 149.05GB used 119.01GB path /dev/sdf
devid6 size 920.34GB used 408.00GB path /dev/sde7
devid7 size 1.36TB used 885.00GB path /dev/sdd
devid4 size 149.05GB used 119.01GB path /dev/sdc
devid2 size 465.76GB used 435.00GB path /dev/sdb
devid8 size 1.36TB used 885.00GB path /dev/sda
*** Some devices missing
stan {~} root# btrfs scrub status /storage
Killed
May 4 07:07:12 stan kernel: btrfs: allowing degraded mounts
May 4 07:07:12 stan kernel: btrfs: disk space caching is enabled
May 4 07:07:12 stan kernel: warning devid 5 missing
May 4 07:07:33 stan kernel: BUG: unable to handle kernel NULL pointer
dereference at (null)
May 4 07:07:33 stan kernel: IP: [] strncpy+0x10/0x30
May 4 07:07:33 stan kernel: PGD 76a1f067 PUD 76a21067 PMD 0
May 4 07:07:33 stan kernel: Oops: [#1] PREEMPT SMP
May 4 07:07:33 stan kernel: CPU 0
May 4 07:07:33 stan kernel: Modules linked in:
May 4 07:07:33 stan kernel:
May 4 07:07:33 stan kernel: Pid: 3283, comm: btrfs Not tainted 3.3.0
#10 To Be Filled By O.E.M. To Be Filled By O.E.M./A770DE+
May 4 07:07:33 stan kernel: RIP: 0010:[]
[] strncpy+0x10/0x30
May 4 07:07:33 stan kernel: RSP: 0018:88007d2e7e10 EFLAGS: 00010206
May 4 07:07:33 stan kernel: RAX: 88007c243c00 RBX: 88007bef0600
RCX: 88007c243c00
May 4 07:07:33 stan kernel: RDX: 0400 RSI:
RDI: 88007c243c00
May 4 07:07:33 stan kernel: RBP: 0062e920 R08:
R09:
May 4 07:07:33 stan kernel: R10: R11: 0246
R12: 88007c243000
May 4 07:07:33 stan kernel: R13: 88007b8fc7d8 R14: 88007c243008
R15: ffed
May 4 07:07:33 stan kernel: FS: 7fa9d7ac7760()
GS:88007fc0() knlGS:
May 4 07:07:33 stan kernel: CS: 0010 DS: ES: CR0:
80050033
May 4 07:07:33 stan kernel: CR2: CR3: 76a28000
CR4: 06f0
May 4 07:07:33 stan kernel: DR0: DR1:
DR2:
May 4 07:07:33 stan kernel: DR3: DR6: 0ff0
DR7: 0400
May 4 07:07:33 stan kernel: Process btrfs (pid: 3283, threadinfo
88007d2e6000, task 88007c83d6a0)
May 4 07:07:33 stan kernel: Stack:
May 4 07:07:33 stan kernel: 8125c3e0 000738e62f87
0040504c 0028
May 4 07:07:33 stan kernel: 0014 88007bc82700
88007b25a930 88007c83d6a0
May 4 07:07:33 stan kernel: 81020eb9 00ff88007bc82760
ff00
May 4 07:07:33 stan kernel: Call Trace:
May 4 07:07:33 stan kernel: [] ?
btrfs_ioctl+0x1000/0x11e0
May 4 07:07:33 stan kernel: [] ?
do_page_fault+0x199/0x420
May 4 07:07:33 stan kernel: [] ? do_vfs_ioctl+0x8e/0x4f0
May 4 07:07:33 stan kernel: [] ? fd_install+0x3c/0x80
May 4 07:07:33 stan kernel: [] ? sys_ioctl+0x49/0x90
May 4 07:07:33 stan kernel: [] ?
system_call_fastpath+0x16/0x1b
May 4 07:07:33 stan kernel: Code: 0f 1f 00 0f b6 0c 16 88 0c 10 48 ff
c2 84 c9 75 f2 f3 c3 0f 1f 84 00 00 00 00 00 48 85 d2 48 89 f8 74 1e 48
89 f9 0f 1f 44 00 00 <0f> b6 3e 40 80 ff 01 40 88 39 48 83 de ff 48 ff
c1 48 ff ca 75
May 4 07:07:33 stan kernel: RIP [] strncpy+0x10/0x30
May 4 07:07:33 stan kernel: RSP
May 4 07:07:33 stan kernel: CR2:
May 4 07:07:33 stan kernel: ---[ end trace 64dfc95061520f57 ]---
--
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
