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
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: '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
