Re: ERROR: unsupported checksum algorithm 35355
Thank you so much for fixing that superblock! Wouldn't even know where to begin myself. btrfs check returned Checking filesystem on /dev/mapper/x UUID: 513f07e1-08be-4d94-a55c-11c6251f6c2f checking extents checking free space cache checking fs roots checking csums checking root refs found 420849201152 bytes used, no error found total csum bytes: 405265360 total tree bytes: 583565312 total fs tree bytes: 56459264 total extent tree bytes: 56328192 btree space waste bytes: 74766514 file data blocks allocated: 440751226880 referenced 419705761792 So I believe everything else looks good. I've successfully mounted the file system and can access all my data. Thanks again, Ken On 03/06/2018 03:45 AM, Qu Wenruo wrote: > Here is the fixed superblock. > > csum type and incompat flags get fixed. > > I'm not sure if they are the only problems, but I strongly recommend to > run btrfs check before mount. > > Thanks, > Qu > > On 2018年03月06日 10:22, Ken Swenson wrote: >> Hi Qu, >> >> attached is the binary super block as requested. >> >> Thank you, >> >> Ken >> >> On 03/05/2018 09:07 PM, Qu Wenruo wrote: >>> On 2018年03月06日 09:51, Ken Swenson wrote: >>>> Hello, >>>> >>>> Somehow it appears the csum_type on my btrfs file system got corrupted. >>>> I cannot mount the system in recovery or read only. btrfs check just >>>> returns "ERROR: unsupported checksum algorithm 35355" as well as btrfs >>>> recover. The only command I was able to successfully run was btrfs >>>> inspect-internal dump-super, which I've pasted the output at the end of >>>> this message. >>>> >>>> Requested information from the wiki: >>>> Linux 4.15.7-1-ARCH #1 SMP PREEMPT Wed Feb 28 19:01:57 UTC 2018 x86_64 >>>> GNU/Linux >>>> btrfs-progs v4.15.1 >>>> btrfs fi show: ERROR: unsupported checksum algorithm 35355 ERROR: cannot >>>> scan /dev/mapper/x: Input/output error >>>> >>>> dmesg: >>>> [ 11.232399] Btrfs loaded, crc32c=crc32c-intel >>>> [ 11.233229] BTRFS: device fsid 513f07e1-08be-4d94-a55c-11c6251f6c2f >>>> devid 1 transid /dev/dm-2 >>>> [ 488.372891] BTRFS error (device dm-2): unsupported checksum algorithm >>>> 35355 >>>> [ 488.372894] BTRFS error (device dm-2): superblock checksum mismatch >>>> [ 488.384902] BTRFS error (device dm-2): open_ctree failed >>>> >>>> Is there anything I can do to recovery from this or am I out of luck? To >>>> give some background the disk was working fine until I upgraded to >>>> Kernel 4.15.7 and rebooted. >>>> >>>> superblock: bytenr=65536, device=/dev/mapper/x >>>> - >>>> csum_type 35355 (INVALID) >>> This is obviously corrupted. >>> >>> Btrfs only supports csum_type 0 (CRC32) yet. >>> >>> And the value seems to be some garbage. >>> >>>> csum_size 32 >>> So is the csum size. >>> >>>> csum >>>> 0xf0dbeddd [match] >>> Surprised to see the csum even matched. >>> >>>> bytenr 65536 >>>> flags 0x1 >>>> ( WRITTEN ) >>>> magic _BHRfS_M [match] >>>> fsid 513f07e1-08be-4d94-a55c-11c6251f6c2f >>>> label >>>> generation >>>> root 186466304 >>>> sys_array_size 129 >>>> chunk_root_generation 7450 >>>> root_level 1 >>>> chunk_root 21004288 >>>> chunk_root_level 1 >>>> log_root 0 >>>> log_root_transid 0 >>>> log_root_level 0 >>>> total_bytes 5000947523584 >>>> bytes_used 420849201152 >>>> sectorsize 4096 >>>> nodesize 16384 >>>> leafsize (deprecated) 16384 >>>> stripesize 4096 >>>> root_dir 6 >>>> num_devices 1 >>>> compat_flags 0x0 >>>> compat_ro_flags 0x0 >>>> incompat_flags 0x176d2169 >>>> ( MIXED_BACKREF | >>>> COMPRESS_LZO | >>>> BIG_METADATA | >>>> EXTENDED_IREF | >>>> SKINNY_METADATA | >>>>
Re: ERROR: unsupported checksum algorithm 35355
Hi Qu, attached is the binary super block as requested. Thank you, Ken On 03/05/2018 09:07 PM, Qu Wenruo wrote: > > On 2018年03月06日 09:51, Ken Swenson wrote: >> Hello, >> >> Somehow it appears the csum_type on my btrfs file system got corrupted. >> I cannot mount the system in recovery or read only. btrfs check just >> returns "ERROR: unsupported checksum algorithm 35355" as well as btrfs >> recover. The only command I was able to successfully run was btrfs >> inspect-internal dump-super, which I've pasted the output at the end of >> this message. >> >> Requested information from the wiki: >> Linux 4.15.7-1-ARCH #1 SMP PREEMPT Wed Feb 28 19:01:57 UTC 2018 x86_64 >> GNU/Linux >> btrfs-progs v4.15.1 >> btrfs fi show: ERROR: unsupported checksum algorithm 35355 ERROR: cannot >> scan /dev/mapper/x: Input/output error >> >> dmesg: >> [ 11.232399] Btrfs loaded, crc32c=crc32c-intel >> [ 11.233229] BTRFS: device fsid 513f07e1-08be-4d94-a55c-11c6251f6c2f >> devid 1 transid /dev/dm-2 >> [ 488.372891] BTRFS error (device dm-2): unsupported checksum algorithm >> 35355 >> [ 488.372894] BTRFS error (device dm-2): superblock checksum mismatch >> [ 488.384902] BTRFS error (device dm-2): open_ctree failed >> >> Is there anything I can do to recovery from this or am I out of luck? To >> give some background the disk was working fine until I upgraded to >> Kernel 4.15.7 and rebooted. >> >> superblock: bytenr=65536, device=/dev/mapper/x >> - >> csum_type 35355 (INVALID) > This is obviously corrupted. > > Btrfs only supports csum_type 0 (CRC32) yet. > > And the value seems to be some garbage. > >> csum_size 32 > So is the csum size. > >> csum >> 0xf0dbeddd [match] > Surprised to see the csum even matched. > >> bytenr 65536 >> flags 0x1 >> ( WRITTEN ) >> magic _BHRfS_M [match] >> fsid 513f07e1-08be-4d94-a55c-11c6251f6c2f >> label >> generation >> root 186466304 >> sys_array_size 129 >> chunk_root_generation 7450 >> root_level 1 >> chunk_root 21004288 >> chunk_root_level 1 >> log_root 0 >> log_root_transid 0 >> log_root_level 0 >> total_bytes 5000947523584 >> bytes_used 420849201152 >> sectorsize 4096 >> nodesize 16384 >> leafsize (deprecated) 16384 >> stripesize 4096 >> root_dir 6 >> num_devices 1 >> compat_flags 0x0 >> compat_ro_flags 0x0 >> incompat_flags 0x176d2169 >> ( MIXED_BACKREF | >> COMPRESS_LZO | >> BIG_METADATA | >> EXTENDED_IREF | >> SKINNY_METADATA | >> unknown flag: 0x176d2000 ) > And unknown flags also exists. > > And according to later output, all backup super blocks have the same > corruption while csum still matches. > > I'm wondering if the memory is corrupted. > > It's possible to manually modify the superblock to a valid status. > As all the corruption is obvious, but I'm not 100% sure if there is > other corruption. > > Please provide the binary superblock dump by: > > dd if= bs=1 count=4K skip=64K of=super_copy > > Thanks, > Qu > >> cache_generation >> uuid_tree_generation >> dev_item.uuid 880c692f-5270-4c7a-908d-8b3956fb3790 >> dev_item.fsid 513f07e1-08be-4d94-a55c-11c6251f6c2f [match] >> dev_item.type 0 >> dev_item.total_bytes 5000947523584 >> dev_item.bytes_used 457439182848 >> dev_item.io_align 4096 >> dev_item.io_width 4096 >> dev_item.sector_size 4096 >> dev_item.devid 1 >> dev_item.dev_group 0 >> dev_item.seek_speed 0 >> dev_item.bandwidth 0 >> dev_item.generation 0 >> sys_chunk_array[2048]: >> item 0 key (FIRST_CHUNK_TREE CHUNK_ITEM 20971520) >> length 8388608 owner 2 stripe_len 65536 type SYSTEM|DUP >> io_align 65536 io_width 65536 sector_size 4096 >> num_stripes 2 sub_stripes 0 >> stripe 0 devid 1 offset 20971520 >> dev_uuid 880c692f-5270-4c7a-908d-8b3956fb3790 >> stripe 1 devid 1 offset 29360128 >> dev_uuid 880c692f-5270-4c7a-908d-8b3956fb3790 >&
ERROR: unsupported checksum algorithm 35355
root 186466304
sys_array_size 129
chunk_root_generation 7450
root_level 1
chunk_root 21004288
chunk_root_level 1
log_root 0
log_root_transid 0
log_root_level 0
total_bytes 5000947523584
bytes_used 420849201152
sectorsize 4096
nodesize 16384
leafsize (deprecated) 16384
stripesize 4096
root_dir 6
num_devices 1
compat_flags 0x0
compat_ro_flags 0x0
incompat_flags 0x176d2169
( MIXED_BACKREF |
COMPRESS_LZO |
BIG_METADATA |
EXTENDED_IREF |
SKINNY_METADATA |
unknown flag: 0x176d2000 )
cache_generation
uuid_tree_generation
dev_item.uuid 880c692f-5270-4c7a-908d-8b3956fb3790
dev_item.fsid 513f07e1-08be-4d94-a55c-11c6251f6c2f [match]
dev_item.type 0
dev_item.total_bytes 5000947523584
dev_item.bytes_used 457439182848
dev_item.io_align 4096
dev_item.io_width 4096
dev_item.sector_size 4096
dev_item.devid 1
dev_item.dev_group 0
dev_item.seek_speed 0
dev_item.bandwidth 0
dev_item.generation 0
sys_chunk_array[2048]:
item 0 key (FIRST_CHUNK_TREE CHUNK_ITEM 20971520)
length 8388608 owner 2 stripe_len 65536 type SYSTEM|DUP
io_align 65536 io_width 65536 sector_size 4096
num_stripes 2 sub_stripes 0
stripe 0 devid 1 offset 20971520
dev_uuid 880c692f-5270-4c7a-908d-8b3956fb3790
stripe 1 devid 1 offset 29360128
dev_uuid 880c692f-5270-4c7a-908d-8b3956fb3790
backup_roots[4]:
backup 0:
backup_tree_root: 181174272 gen: 7774 level: 1
backup_chunk_root: 21004288 gen: 7450 level: 1
backup_extent_root: 181190656 gen: 7774 level: 2
backup_fs_root: 809828352 gen: 6404 level: 0
backup_dev_root: 93585408 gen: 7631 level: 1
backup_csum_root: 181862400 gen: 7774 level: 2
backup_total_bytes: 5000947523584
backup_bytes_used: 420849201152
backup_num_devices: 1
backup 1:
backup_tree_root: 183828480 gen: 7775 level: 1
backup_chunk_root: 21004288 gen: 7450 level: 1
backup_extent_root: 183320576 gen: 7775 level: 2
backup_fs_root: 809828352 gen: 6404 level: 0
backup_dev_root: 183975936 gen: 7775 level: 1
backup_csum_root: 185761792 gen: 7775 level: 2
backup_total_bytes: 5000947523584
backup_bytes_used: 420849201152
backup_num_devices: 1
backup 2:
backup_tree_root: 186810368 gen: 7776 level: 1
backup_chunk_root: 21004288 gen: 7450 level: 1
backup_extent_root: 186613760 gen: 7776 level: 2
backup_fs_root: 809828352 gen: 6404 level: 0
backup_dev_root: 183975936 gen: 7775 level: 1
backup_csum_root: 187056128 gen: 7776 level: 2
backup_total_bytes: 5000947523584
backup_bytes_used: 420849201152
backup_num_devices: 1
backup 3:
backup_tree_root: 186466304 gen: level: 1
backup_chunk_root: 21004288 gen: 7450 level: 1
backup_extent_root: 187908096 gen: level: 2
backup_fs_root: 809828352 gen: 6404 level: 0
backup_dev_root: 183975936 gen: 7775 level: 1
backup_csum_root: 188071936 gen: level: 2
backup_total_bytes: 5000947523584
backup_bytes_used: 420849201152
backup_num_devices: 1
Thank you,
Ken
N�r��yb�X��ǧv�^�){.n�+{�n�߲)w* jg��� �ݢj/���z�ޖ��2�ޙ&�)ߡ�a���� �G���h��j:+v���w��٥
trying to balance, filesystem keeps going read-only.
I have a file system of four 5TB drives. Well, one drive is 8TB with a
5TB partition.. the rest are 5TB drives. I created the initial btrfs
file system on on drive. rsync'd data to it. added another drive.
rsync'd data. added a third drive, rsync'd data. Added a four drive,
trying to balance. The file system gets an error and I have to reboot
to get the file system out of read only.
I dont think it is hardware issue..but It could be... or it could be
some kind bug in btrfs?
To recover.. I've been comment out the btrfs in fstab, shutdown..
power off.. verify cable connections. Power on. verify all the devices
are present.. remount.
This kind of balance was successful:
btrfs balance start -dusage=55 /mnt/magenta/
but this gets the error below and goes into Read-only:
btrfs filesystem balance /mnt/magenta/
my kernel now is:
Linux ubuntu 4.2.0-17-lowlatency #21-Ubuntu SMP PREEMPT Fri Oct 23
20:40:07 UTC 2015 x86_64 x86_64 x86_64 GNU/Linux
~# btrfs filesystem show
Label: 'uv000' uuid: f974efbd-82cb-4812-a3b3-eb12ae470f2c
Total devices 4 FS bytes used 11.17TiB
devid1 size 4.77TiB used 4.26TiB path /dev/sdf1
devid2 size 4.55TiB used 4.09TiB path /dev/sde
devid3 size 4.55TiB used 2.74TiB path /dev/sdb
devid4 size 4.55TiB used 96.03GiB path /dev/sdg
Label: 'LinuxSampler' uuid: 55aa3bf2-f319-42c7-8f1d-20ee35a91f9a
Total devices 1 FS bytes used 555.80GiB
devid1 size 2.51TiB used 558.04GiB path /dev/sdf2
# btrfs filesystem df /mnt/btrfs/
Data, single: total=11.16TiB, used=11.16TiB
System, RAID1: total=32.00MiB, used=1.20MiB
Metadata, RAID1: total=10.00GiB, used=8.29GiB
Metadata, DUP: total=4.50GiB, used=4.21GiB
GlobalReserve, single: total=512.00MiB, used=0.00B
# btrfs filesystem usage /mnt/btrfs/
Overall:
Device size: 18.41TiB
Device allocated: 11.19TiB
Device unallocated: 7.22TiB
Device missing: 0.00B
Used: 11.18TiB
Free (estimated): 7.22TiB (min: 3.61TiB)
Data ratio: 1.00
Metadata ratio: 2.00
Global reserve: 512.00MiB (used: 0.00B)
Data,single: Size:11.16TiB, Used:11.16TiB
/dev/sdb 2.73TiB
/dev/sde 4.09TiB
/dev/sdf1 4.25TiB
/dev/sdg 93.00GiB
Metadata,RAID1: Size:10.00GiB, Used:8.29GiB
/dev/sdb 5.00GiB
/dev/sde 6.00GiB
/dev/sdf1 6.00GiB
/dev/sdg 3.00GiB
Metadata,DUP: Size:4.50GiB, Used:4.21GiB
/dev/sdf1 9.00GiB
System,RAID1: Size:32.00MiB, Used:1.20MiB
/dev/sdb 32.00MiB
/dev/sdg 32.00MiB
Unallocated:
/dev/sdb 1.81TiB
/dev/sde 465.53GiB
/dev/sdf1 515.80GiB
/dev/sdg 4.45TiB
and the tail of dmesg -
[50363.836660] ata10: EH complete
[64894.794201] BTRFS info (device sdb): relocating block group
12704106414080 flags 1
[64899.944105] BTRFS info (device sdb): found 124 extents
[64906.622024] BTRFS info (device sdb): found 124 extents
[64906.915197] BTRFS info (device sdb): relocating block group
12703032672256 flags 1
[64915.409311] BTRFS info (device sdb): found 813 extents
[64947.160961] ata10.00: exception Emask 0x0 SAct 0x7fff SErr 0x0
action 0x6 frozen
[64947.160966] ata10.00: failed command: WRITE FPDMA QUEUED
[64947.160970] ata10.00: cmd 61/c0:00:38:8a:1d/0f:00:0c:00:00/40 tag 0
ncq 2064384 out
res 40/00:01:00:4f:c2/00:00:00:00:00/00 Emask
0x4 (timeout)
[64947.160975] ata10.00: status: { DRDY }
[64947.160977] ata10.00: failed command: WRITE FPDMA QUEUED
[64947.160980] ata10.00: cmd 61/80:08:f8:99:1d/0a:00:0c:00:00/40 tag 1
ncq 1376256 out
res 40/00:01:00:00:00/00:00:00:00:00/00 Emask
0x4 (timeout)
[64947.160981] ata10.00: status: { DRDY }
[64947.160982] ata10.00: failed command: WRITE FPDMA QUEUED
[64947.160985] ata10.00: cmd 61/c0:10:78:a4:1d/0f:00:0c:00:00/40 tag 2
ncq 2064384 out
res 40/00:01:00:4f:c2/00:00:00:00:00/00 Emask
0x4 (timeout)
[64947.160987] ata10.00: status: { DRDY }
[64947.160988] ata10.00: failed command: WRITE FPDMA QUEUED
[64947.160991] ata10.00: cmd 61/80:18:38:b4:1d/0a:00:0c:00:00/40 tag 3
ncq 1376256 out
res 40/00:01:00:4f:c2/00:00:00:00:00/00 Emask
0x4 (timeout)
[64947.160992] ata10.00: status: { DRDY }
[64947.160994] ata10.00: failed command: WRITE FPDMA QUEUED
[64947.160996] ata10.00: cmd 61/c0:20:b8:be:1d/0f:00:0c:00:00/40 tag 4
ncq 2064384 out
res 40/00:00:00:4f:c2/00:00:00:00:00/40 Emask
0x4 (timeout)
[64947.160998] ata10.00: status: { DRDY }
[64947.160999] ata10.00: failed command: WRITE FPDMA QUEUED
[64947.161002] ata10.00: cmd 61/40:28:78:ce:1d/1a:00:0c:00:00/40 tag 5
ncq 3440640 out
res 40/00:01:00:00:00/00:00:00:00:00/00 Emask
0x4 (timeout)
[64947.161003] ata10.00: status: { DRDY }
[64947.161005] ata10.00: failed command: WRITE FPDMA QUEUED
[64947.161007] ata10.00: cmd 61/40:30:b8:e8:1d/1a:00:0c:00:00/40 tag 6
ncq 3440640 out
res 40/00:01:00:4f:c2/00:00:00:00:00/00 Emask
0x4 (timeout)
[64947.161009] ata10.00: status: { DRDY }
[64947.161010]
Re: trying to balance, filesystem keeps going read-only.
I get a similar read-only status when I try to remove the drive from the array.. Too bad the utility's function can not be slowed down.. to avoid triggering this error... ? I had some success putting data *onto* the drive by croning sync every two seconds in a different terminal. Doesn't seem to be fixed yet.. https://bugzilla.kernel.org/show_bug.cgi?id=93581 On Sun, Nov 1, 2015 at 9:17 AM, Roman Mamedov <r...@romanrm.net> wrote: > On Sun, 1 Nov 2015 09:07:08 -0500 > Ken Long <kelargo1...@gmail.com> wrote: > >> Yes, the one drive is that Seagate 8TB drive.. >> >> Smart tools doesn't show anything outrageous or obvious in hardware. >> >> Is there any other info I can provide to isolate, troubleshoot further? >> >> I'm not sure how to correlate the dmesg message to a specific drive, >> SATA cable etc.. > > See this discussion: http://www.spinics.net/lists/linux-btrfs/msg48054.html > > My guess is these drives need to do a lot of housekeeping internally, > especially during heavy write load or random writes, and do not reply to the > host machine in time, which translates into those "frozen [...] failed > command: WRITE FPDMA QUEUED" failures. > > I did not follow the issue closely enough to know if there's a solution yet, > or > even if this is specific to Btrfs or to GNU/Linux in general. Maybe your best > bet would be to avoid using that drive in your Btrfs array altogether for the > time being. > > -- > With respect, > Roman -- 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: trying to balance, filesystem keeps going read-only.
Yes, the one drive is that Seagate 8TB drive.. Smart tools doesn't show anything outrageous or obvious in hardware. Is there any other info I can provide to isolate, troubleshoot further? I'm not sure how to correlate the dmesg message to a specific drive, SATA cable etc.. On Sun, Nov 1, 2015 at 8:48 AM, Roman Mamedov <r...@romanrm.net> wrote: > On Sun, 1 Nov 2015 06:24:53 -0500 > Ken Long <kelargo1...@gmail.com> wrote: > >> Well, one drive is 8TB with a 5TB partition. > > Is this by any chance a Seagate "SMR" drive? From what I remember seeing on > the list, those do not work well with Btrfs currently, with symptoms very > similar to what you're seeing. > > -- > With respect, > Roman -- 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 with 8TB SMR drives
Hello, I have a a single version of this drive formatted with btrfs. Its my only btrfs drive on this machine. I'm getting similar errors. Is there any info I can provide to help troubleshoot this? Is a full dmesg still wanted? here's what I'm running- $ uname -a Linux machine 4.2.0-16-lowlatency #19-Ubuntu SMP PREEMPT Thu Oct 8 16:19:23 UTC 2015 x86_64 x86_64 x86_64 GNU/Linux -- 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 send erroring...
Hi! Trying to do a btrfs send, and failing with: root@khamul:~# btrfs send /biggie/BACKUP/ | btrfs receive /tmp/sdd1/ At subvol /biggie/BACKUP/ At subvol BACKUP ERROR: rename o2046806-17126-0 - volumes/ccdn-ch2-01 failed. No such file or directory Judging by disk capacity, it hits this about 40% of the way through. As my disk has subvolumes on it, which are underneath /biggie/BACKUP/, is there a different way I should go about sending an entire disk? Thanks! -Ken -- 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 send erroring...
On 2014-11-20 12:11, Hugo Mills wrote: On Thu, Nov 20, 2014 at 11:57:50AM -0500, Ken D'Ambrosio wrote: Hi! Trying to do a btrfs send, and failing with: root@khamul:~# btrfs send /biggie/BACKUP/ | btrfs receive /tmp/sdd1/ At subvol /biggie/BACKUP/ At subvol BACKUP ERROR: rename o2046806-17126-0 - volumes/ccdn-ch2-01 failed. No such file or directory This looks like one of several bugs that have been fixed recently. What kernel version and userspace tools version are you using? 3.11... older than I'd realized! Guess it's time for an upgrade, eh? I'll give that a go -- thanks for the pointer! -Ken -- 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: Fwd: Is there a lightweight copy from one subvolume to another?
On 25/01/2014 7:17 PM, Marc MERLIN wrote: On Sat, Jan 25, 2014 at 09:50:48PM +1300, Maxdamantus wrote: Due to what I understand is some VFS limitation, you can only reflink-copy between subvolumes under one Linux mountpoint. If /mnt/btrfs1 provides access to all subvolumes, you should be able to copy between them through that path, but you won't be able to copy them across mounts, even `--bind` ones. That was exactly my understanding too. gargamel [mc]# cp -av --reflink=always misc/olympic Video/misc/ `misc/olympic' - `Video/misc/olympic' `misc/olympic/file.avi' - `Video/misc/olympic/file.avi' cp: failed to clone `Video/misc/olympic/file.avi' from `misc/olympic/file.avi': Invalid cross-device link The test above was done in /mnt/btrfs_pool1 and failed as shown here. Yet gargamel:/mnt/btrfs_pool1# btrfs subvolume list . ID 257 top level 5 path misc ID 258 top level 5 path Video ID 259 top level 5 path media ID 260 top level 5 path Sound ID 261 top level 5 path zoneminder ID 262 top level 5 path other Aah, but it looks like this was my problem: 'Preparing to replace coreutils 8.13-3.2 (using .../coreutils_8.21-1_i386.deb) ... now cp --reflink works as expected. Thanks, Marc If I recall correctly you also need a kernel = 3.7. Which I assume you have if this is now working. Ken. -- 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
Will RAID have issues with disks that spin down?
Hi. I know that several hardware RAID solutions have issues with disks that spin down when idle; the time to spin back up -- usually on the order of five seconds -- causes unhappy timeouts, etc. I was wondering if that would be an issue with RAID a-la btrfs? Thanks, -Ken -- 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
Yet Another Newb Question...
(Asking this question on this list kinda makes me wonder if there shouldn't be a btrfs-users list where folks could ask questions just like this without pestering developers...) Anyway -- I had a root partition with a /snapshots directory, in which I placed a bunch of snapshots. At one point, I goofed stuff up, and decided to revert my root (using btrfs sub set-default) to one of the snapshots. Rebooted, and it worked great -- just like I'd hoped. But where'd the snapshots in /snapshots go? I mean, I still see them if I do a btrfs sub list, but how do I *get* to them for, say, deleting? (I can still mount them via -o subvolid, but that's not quite the same thing.) Suggestions? Thanks kindly! -Ken -- 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/git question.
Seems I've picked up a wireless regression, and randomly drop my WiFi connection with more recent kernels. While I'd love to try to track down the issue, the sporadic nature makes it difficult. But I don't want to revert to a flat-out old kernel because of all the btrfs modifications. Is it possible using git to add *just* btrfs patches to an older kernel? Thanks, -Ken -- 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: mount errors
1) As of right now, btrfs's fsck is done when it's done. So don't hold your breath, I'm afraid. 2) What errors do you get on mount? It may be as simple as changing your fstab entry such that fsck isn't attempted to be run. (Change the last column to 0.) -Ken On Sat, 19 Nov 2011 14:01:41 +0100 René Vangsgaard rene.vangsga...@gmail.com wrote Hi - I have been using btrfs on /home for 2 weeks, and now it mounts with errors. I know that no fsck is available yet. I ignore the error and it still works, for now. Can I do anything to help you debug this problem with btrfs? Any news on fsck for btrfs? I am running Ubuntu 11.10. Thank you, René -- 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 -- 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: Stupid newb tricks: making a subvolume of root.
On Thu, 10 Nov 2011 14:59:44 + Hugo Mills h...@carfax.org.uk wrote Alternatively, if you want the top level to be simply a container for subvolumes (and to use a default subvolume to mount / ), then you could do the switch-over by making a snapshot of your current /, remounting with the snapshot as / (possibly using btrfs sub set-default), and then mounting subvolid=0 on /media/btrfs-management to delete the old contents of / So, I did this. I think correctly: mkdir /tmp/foo mount /dev/sda1 /tmp/foo -o subvolid=0 And lo! I did an ls, and everything was there. And then the kernel panic'd. I rebooted, re-mounted, and it was there again. And then the kernel panic'd. Last time, I didn't even try an ls -- I just did a btrfs subvol list /tmp/foo, and yet another panic. This is running 3.2rc1 (with tools built off the git repository on kernel.org, if that makes any difference). My system is, technically, working. Any suggestions on how to get rid of my old root? Thanks... -Ken -- 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: Stupid newb tricks: making a subvolume of root.
On Fri, 11 Nov 2011 19:13:09 + Hugo Mills h...@carfax.org.uk wrote I'd suggest reporting (on this mailing list) the panic message(s) you got, and how you got to them. I know there's been quite a few additional patches worked on since Chris pushed out the stack for -rc1, so it's quite plausible that your particular problem has already been fixed in someone's tree. Hmmm. I just pulled Chris's tree, and it seems to have done the trick. It's mounting, now. I'm being leery of outright deleting, because grub-mkconfig seems confused about being mounted off a different subvolume: grub-probe: error: cannot find a device for / (is /dev/mounted?). (Needless to say, /dev/ *is* mounted. Likely, I've somehow confused it with fstab or something.) But I'm able to look at directories, cat/cp files, etc., so I now at least *could* blow things away. Which is handy. Thanks! -Ken -- 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
Stupid newb tricks: making a subvolume of root.
Hey, all. I did a convert on my ext-3 system, and now I've got a monolithic btrfs volume. I'd like to break / and /home into subvolumes. /home is easy (I think): I just create a subvolume, and move stuff into it, and mount it. Done. But how do I do that for root? (Don't worry about the actual mounting, grub, etc.,; I have a different system that works the way I want it to.) Thanks, -Ken -- 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
Unable to mount (or, why not to work late at night).
So, I was trying to downgrade my Ubuntu last night, and, before doing anything risky like that, I backed up my disk via dd to an image on an external disk. The critical part here is that I'm afraid I did something truly stupid: I'm afraid I did the dd... live. (I can't swear to this, and it does seem unlikely, but it also seems to be the most likely circumstance.) So, I dd'd everything back, and now it crashes on boot. Booting to a 2.6.x kernel (which is what I had on-hand on a USB drive) mounts it, but doesn't let me *do* anything (though it spews btrfs errors in dmesg). Getting Ubuntu 11.10 (kernel rev. 3.0.0) gives me this: [ 121.226246] device fsid d657ce6a-d353-4c2c-858a-6a1f4d9e766e devid 1 transid 217713 /dev/sda1 [ 121.232430] parent transid verify failed on 100695031808 wanted 217713 found 217732 [ 121.232898] parent transid verify failed on 100695031808 wanted 217713 found 217732 [ 121.233357] parent transid verify failed on 100695031808 wanted 217713 found 217732 [ 121.233365] parent transid verify failed on 100695031808 wanted 217713 found 217732 [ 121.248231] btrfs: open_ctree failed As I have this complete image on-disk, I'm more than willing to try Extreme Measures(tm), whatever that might entail. If I can't get it back, it's not like it's the loss of my job or anything, but there *is* stuff I'd really like to get back. Thanks, -Ken -- 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: Unable to mount (or, why not to work late at night).
some of us make use of snapshot/clone, whether it's using btrfs or zfs :) No, this is just flat my fault: it doesn't matter what backup method you use if you do it wrong. (I actually have three snapshots of each of my two partitions.) What do you mean don't let you do anything? Can you mount it read-only and copy the data off the disk? You can mount it on the older kernels, but, once you try any form of access, you can watch your load spike as it spews errors into dmesg. I'd try 3.1. If you use 11.10 try http://kernel.ubuntu.com/~kernel-ppa/mainline/v3.1-oneiric/ 3.1 is what the system had been running; it simply panics when trying to mount the FS. Try getting source of btrfs-progs, do make btrfs-zero-log, and use it. Already got 'em. Everything that tries to even think about modifying stuff (btrfs-zero-log, btrfsck, and btrfs-debug-tree) all dump core: root@ubuntu:/tmp/btrfs-progs# ./btrfs-zero-log /dev/sda1 parent transid verify failed on 100695031808 wanted 217713 found 217732 parent transid verify failed on 100695031808 wanted 217713 found 217732 parent transid verify failed on 100695031808 wanted 217713 found 217732 btrfs-zero-log: disk-io.c:413: find_and_setup_root: Assertion '!(!root-node)' failed. Aborted (core dumped) -Ken -- 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: too many files open
Well, I hate to grasp for a flyswatter when a hammer might be better, but what's /proc/sys/fs/file-nr show? The first number is your currently opened files, the last one is your maximum files (as dictated by /proc/sys/fs/file-max), and the middle one's allocated-but-unused file handles. If it's showing a number anything near your max files, it's probably a fine time to check out lsof. Looking for where the disparity lies will probably offer some insights, I imagine. $.02, -Ken On Wed, 05 Oct 2011 11:54:35 -0400 Jim j...@webstarts.com wrote Checked ulimit and processes are not the issue here. Rsync never has more than 15 instances running and even accounting for children and other processes they wouldnt approach the process limit. The error ddoes seem to be with btrfs as I cant ls the file system while this condition exists. Ls also returns too many files open. Btrfs sub list also shows the same too many files open condition. Actually, there should be no files open after the script has failed (the script runs, just reports the errors). Something either reports files as being open or is holding them open, and a remount flushes this and the fs is back to normal. Very confusing. Jim On 10/05/2011 11:32 AM, Jim wrote: Thanks very much for the idea. I will check and get back. Jim On 10/05/2011 11:31 AM, Roman Mamedov wrote: On Wed, 05 Oct 2011 11:24:27 -0400 Jimj...@webstarts.com wrote: Good morning Btrfs list, I have been loading a btrfs file system via a script rsyncing data files from an nfs mounted directory. The script runs well but after several days (moving about 10TB) rsync reports that it is sending the file list but stops moving data because btrfs balks saying too many files open. A simple umount/mount fixes the problem. What am I flushing when I remount that would affect this, and is there a way to do this without a remount. Once again thanks for any assistance. Are you sure it's a btrfs problem? Check ulimit -n, see help ulimit (assuming you use bash). -- 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 -- 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
RAID not RAIDing? Or at least not showing correct usage?
Hi, all. I'd never done RAID on btrfs before, so bear with me if I'm missing something obvious. I just created a RAIDed btrfs partition with mkfs.btrfs -m raid10 -d raid10 -L bigguy /dev/sdb /dev/sdc (I also did the same, but with RAID-1, getting the same results I'm about to outline.) That's two 3-TB disks; since they're RAIDed, I expected to wind up with ~3 TB of free space. But df reports 5858378624 available. Knowing that df and btrfs don't always see eye-to-eye, I copied over a 350 MB .avi, and fired up btrfs-show, which came back with: Label: bigguy uuid: 5e062e02-f55e-4d7f-866c-3b851b3c6e02 Total devices 2 FS bytes used 350.57MB devid1 size 2.73TB used 1.27GB path /dev/sdb devid2 size 2.73TB used 0.00 path /dev/sdc That don't look very mirrored to me. All the instructions I found said I should just mount /dev/sd(b|c) singly; is there, instead, a logical RAID partition I should be mounting? Or... is there something else I'm just missing? Thanks, and apologies if my ignorance is showing, -Ken -- 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
[no subject]
Just wondering if/how one goes about getting the btrfs checksum of a given file. Is there a way? Thanks! -Ken -- 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: [RFC] btrfs auto snapshot
and much easier than trying to get snapper to compile on fedora libblocxx ? :-) Ken On 8/17/2011 9:04 AM, Dave wrote: I've already done something similar. I take hourly, daily, weekly, and monthly snapshots of my /home subvolume. Here's the script I've created for this: #! /bin/bash if [ $# -ne 2 ]; then echo Usage $0 SNAPSHOT_PREFIX NUM_SNAPSHOTS exit 1 fi SNAPS=/var/lib/btrfs-root/__snapshot/home btrfs subvolume snapshot -r /home $SNAPS/$1_$(date +%F_%T.%N) num_snaps=$(ls -1d $SNAPS/$1_* | sort | wc -l) if [ $num_snaps -gt $2 ]; then let over=$num_snaps-$2 ls -1d $SNAPS/$1_* | head -n $over | while read s; do btrfs subvolume delete $s done fi Here's my crontab: 0 * * * * /usr/local/bin/snapshot hourly 6 0 0 * * * /usr/local/bin/snapshot daily 7 0 0 * * 0 /usr/local/bin/snapshot weekly 4 -- Ken Anderson -- 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 0/2] btrfs: allow cross-subvolume BTRFS_IOC_CLONE
On Fri, 2011-04-01 at 09:34 -0400, Christoph Hellwig wrote: On Thu, Mar 31, 2011 at 08:02:22AM -0400, Chris Mason wrote: Excerpts from Christoph Hellwig's message of 2011-03-31 02:36:36 -0400: On Thu, Mar 31, 2011 at 12:00:11AM -0400, Larry D'Anna wrote: This is a simple patch to allow reflinks to be made crossing subvolume boundaries. NAK. subvolumes will have to become vfsmounts sooner or later, and we really must not support any operations spanning mountpoints. Sorry, I disagree here. reflinks were always intended to be able to span subvolumes. There's no conflict at all because they span different inodes. I don't think it's a good idea to introduce any user visible operations over subvolume boundaries. Currently we don't have any operations over mount boundaries, which is pretty fumdamental to the unix filesystem semantics. If you want to change this please come up with a clear description of the semantics and post it to linux-fsdevel for discussion. That of course requires a clear description of the btrfs subvolumes, which is still completely missing. I don't really understand the details here, but doesn't the creation of a snapshot already lead to data extents being shared between sub-volumes? From a simple user perspective this sounds like a very useful capability. -- 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: 'open_ctree failed', unable to mount the fs
On Fri, January 7, 2011 2:09 pm, Hugo Mills wrote: On Fri, Jan 07, 2011 at 08:01:47PM +0100, Tomasz Chmielewski wrote: I got a power cycle, after which I'm no longer able to mount btrfs filesystem: [...] The forthcoming[1] btrfsck tool should handle that particular error, I believe. I tried it with the btrfsck in the git repo (last week), and wound up with... a brandy-new, blank btrfs partition. Not *quite* what I was looking for. But at least it mounted. -K -- 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
Failed to read block groups -- is this a problem?
Hey, all. I'm dealing with a potentially flaky 3Ware controller. Got seven 2 TB disks in a RAID-6. The BTRFS partition is a 9 TB partition. I've had to do a couple hard shutdowns on the system, and now I'm getting sporadic Failed to read block groups errors in dmesg: r...@parsley:~# dmesg | egrep Failed to read block groups:|btrfs [ 27.184179] Failed to read block groups: -5 [ 27.295231] btrfs: open_ctree failed [ 2758.862565] Failed to read block groups: -5 [ 2758.896175] btrfs: open_ctree failed [ 3292.539509] Failed to read block groups: -5 [ 3292.591306] btrfs: open_ctree failed Is this a Bad Thing? Is there something I should do to try to rectify this? Running Ubuntu with its 2.6.37-11-server kernel (64-bit). Thanks! -Ken -- 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
du reporting odd file sizes during copy.
Hi, all. I was copying two 6-GB DVD images yesterday, and while monitoring the copy progress, noticed that du would show a trend that *generally* headed toward the final files' sizes, but on occasion would hop backward, thusly: r...@hal-9000:/shared/ISOs# while true; do du * ; sleep 10; echo;done 1151808 SolidWorks_2008_32-bit.iso 1928784 SolidWorks_2008_64-bit.iso 1072032 SolidWorks_2008_32-bit.iso 1763280 SolidWorks_2008_64-bit.iso 1044384 SolidWorks_2008_32-bit.iso 2097152 SolidWorks_2008_64-bit.iso 1481248 SolidWorks_2008_32-bit.iso 2183184 SolidWorks_2008_64-bit.iso The images did copy, but I'm just curious as to what the mechanics were behind du's seemingly non-linear reporting. (If it makes any difference, one copy was coming in via an ssh pipe from a different machine; the other was being copied from the local CD drive. Both were using cat to write the files.) Thanks, -Ken -- This message has been scanned for viruses and dangerous content by MailScanner, and is believed to be clean. -- 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
Hardlinks-per-directory limit?
Hello, all. I'm thinking of rolling out a BackupPC server, and -- based on the strength of the recent Phoronix benchmarks (http://benchmarkreviews.com/index.php?option=com_contenttask=viewid=11156Itemid=23) -- had been strongly considering btrfs. But I do seem to recall that there was some sort of hardlinks-per-directory limitation, and BackupPC *loves* hardlinks. Would someone care to either remind me what the issue was, or reassure me that it's been rectified? Thanks! -Ken -- This message has been scanned for viruses and dangerous content by MailScanner, and is believed to be clean. -- 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: Status of BTRFS
Yes, Fedora is one of the releases that has officially supported it for a while now. Additionally an initrd hook for btrfs has just been implemented for Arch Linux, so you might see btrfs being an option for that in the next version of the installer :-) I also believe that Ubuntu 10.10 is slated to have it; I think it's in the current alpha, though based on my reading, there are still some rough edges. I think Fedora's actually got a rollback feature, using snapshots, which should be super nice -- hopefully, others come up with similar features to take advantage of btrfs's features. -Ken -- This message has been scanned for viruses and dangerous content by MailScanner, and is believed to be clean. -- 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/iSCSI/sparse file OOPS.
Hey, all. I've tried repeatedly to get an 800 GB sparse file on a 1 TB btrfs partition to work as an iSCSI target... and I can run fdisk on it (and see the iSCSI disk just fine), but when I try to create a partition and exit, it OOPSes every time. Ubuntu, kernel 2.6.31-13-generic is the latest I've tried. Is this a known bug? I've tried Googling to no avail. If there's anything I can do to help troubleshoot, please let me know. Thanks! -Ken P.S. FYI, tried the same thing on a reiserfs partition on the same system, worked fine. - dmesg dump --- [ 6310.208547] Loading iSCSI transport class v2.0-870. [ 6310.229328] iscsi: registered transport (tcp) [ 6310.273236] iscsi: registered transport (iser) [ 6310.552757] scsi4 : iSCSI Initiator over TCP/IP [ 6310.812801] scsi 4:0:0:0: Direct-Access IET VIRTUAL-DISK 0 PQ: 0 ANSI: 4 [ 6310.812950] sd 4:0:0:0: Attached scsi generic sg3 type 0 [ 6310.817523] sd 4:0:0:0: [sdc] 1572864000 512-byte logical blocks: (805 GB/750 GiB) [ 6310.817743] sd 4:0:0:0: [sdc] Write Protect is off [ 6310.817748] sd 4:0:0:0: [sdc] Mode Sense: 77 00 00 08 [ 6310.817883] sd 4:0:0:0: [sdc] Write cache: disabled, read cache: enabled, doesn't support DPO or FUA [ 6310.819622] sdc: unknown partition table [ 6310.822547] sd 4:0:0:0: [sdc] Attached SCSI disk [ 6524.480833] BUG: unable to handle kernel NULL pointer dereference at (null) [ 6524.480840] IP: [(null)] (null) [ 6524.480843] *pde = [ 6524.480846] Oops: [#1] SMP [ 6524.480849] last sysfs file: /sys/kernel/uevent_seqnum [ 6524.480852] Modules linked in: ib_iser rdma_cm ib_cm iw_cm ib_sa ib_mad ib_core ib_addr iscsi_tcp libiscsi_tcp libiscsi scsi_transport_iscsi iscsi_trgt nfsd exportfs nfs lockd nfs_acl auth_rpcgss sunrpc btrfs zlib_deflate crc32c libcrc32c snd_hda_codec_realtek snd_hda_intel snd_hda_codec snd_usb_audio snd_pcm_oss snd_mixer_oss snd_pcm snd_usb_lib snd_hwdep snd_seq_dummy snd_seq_oss snd_seq_midi snd_rawmidi snd_seq_midi_event snd_seq snd_timer snd_seq_device snd snd_page_alloc lp ppdev psmouse soundcore parport_pc parport serio_raw binfmt_misc reiserfs raid10 raid456 raid6_pq async_xor async_memcpy async_tx xor raid1 raid0 multipath linear fbcon tileblit font bitblit softcursor usbhid floppy tg3 i915 drm i2c_algo_bit video output intel_agp agpgart [last unloaded: scsi_transport_iscsi] [ 6524.480917] [ 6524.480920] Pid: 2541, comm: istiod1 Not tainted (2.6.31-13-generic #43-Ubuntu) HP Compaq dc5700 Small Form Factor [ 6524.480923] EIP: 0060:[] EFLAGS: 00010282 CPU: 0 [ 6524.480928] EIP is at 0x0 [ 6524.480930] EAX: f417be18 EBX: f964b660 ECX: 0001 EDX: f417be9c [ 6524.480932] ESI: f4082380 EDI: f417be18 EBP: f417beb0 ESP: f417be0c [ 6524.480935] DS: 007b ES: 007b FS: 00d8 GS: 00e0 SS: 0068 [ 6524.480937] Process istiod1 (pid: 2541, ti=f417a000 task=f65e7110 task.ti=f417a000) [ 6524.480939] Stack: [ 6524.480941] c01e28dc 0400 0001 [ 6524.480947] 0 f4082380 f65e7110 [ 6524.480954] 0 f65e7110 f65e7110 c0157970 f417be58 f417be58 f65e713c [ 6524.480962] Call Trace: [ 6524.480969] [c01e28dc] ? do_sync_write+0xbc/0x100 [ 6524.480974] [c0157970] ? autoremove_wake_function+0x0/0x40 [ 6524.480983] [fb3d7e8a] ? fileio_make_request+0x11a/0x200 [iscsi_trgt] [ 6524.480990] [fb3d7d70] ? fileio_make_request+0x0/0x200 [iscsi_trgt] [ 6524.480997] [fb3d011b] ? tio_write+0x1b/0x60 [iscsi_trgt] [ 6524.481001] [c0133797] ? finish_task_switch+0x57/0xe0 [ 6524.481008] [fb3d8a41] ? build_write_response+0x31/0xc0 [iscsi_trgt] [ 6524.481012] [c056962c] ? schedule+0x40c/0x730 [ 6524.481018] [fb3d36c3] ? send_scsi_rsp+0x13/0xd0 [iscsi_trgt] [ 6524.481025] [fb3d8944] ? disk_execute_cmnd+0x194/0x1c0 [iscsi_trgt] [ 6524.481031] [fb3d4e1e] ? worker_thread+0xbe/0x1b0 [iscsi_trgt] [ 6524.481035] [c0137ca0] ? default_wake_function+0x0/0x10 [ 6524.481040] [fb3d4d60] ? worker_thread+0x0/0x1b0 [iscsi_trgt] [ 6524.481043] [c015767c] ? kthread+0x7c/0x90 [ 6524.481046] [c0157600] ? kthread+0x0/0x90 [ 6524.481050] [c0103f17] ? kernel_thread_helper+0x7/0x10 [ 6524.481052] Code: Bad EIP value. [ 6524.481056] EIP: [] 0x0 SS:ESP 0068:f417be0c [ 6524.481066] CR2: [ 6524.481069] ---[ end trace 3e23029014423010 ]--- [ 6617.88] iscsi_trgt: cmnd_abort(1149) 5c00 1 0 42 4096 0 0 [ 6617.93] iscsi_trgt: Abort Task (01) issued on tid:1 lun:0 by sid:281474997486080 (Unknown Task) [ 6617.000139] iscsi_trgt: Logical Unit Reset (05) issued on tid:1 lun:0 by sid:281474997486080 (Function Complete) [ 6617.000200] BUG: unable to handle kernel NULL pointer dereference at (null) [ 6617.000205] IP: [(null)] (null) [ 6617.000208] *pde = be212067 [ 6617.000211] Oops: [#2] SMP [ 6617.000214] last sysfs file: /sys/kernel/uevent_seqnum [ 6617.000217] Modules linked in: ib_iser rdma_cm ib_cm iw_cm
