overflow in inode.c, file.c
Hello, while using linux-4.2.3 (btrfs-progs v4.2.2) with the latest grsec patch to date, a feature in the grsec patchset, an overflow checker (made by emese) seems to have found some bugs in the btrfs code itself (this is not caused by grsec). First bug: fs/btrfs/inode.c:5759 For example --> *** Oct 18 16:09:18 TestMachine kernel: [8.449128] PAX: size overflow detected in function btrfs_real_readdir fs/btrfs/inode.c:5760 cicus.935_282 max, count: 9, decl: pos; num: 0; context: dir_context; Oct 18 16:09:18 TestMachine kernel: [8.449132] CPU: 0 PID: 2630 Comm: polkitd Not tainted 4.2.3-grsec #1 Oct 18 16:09:18 TestMachine kernel: [8.449134] Hardware name: Gigabyte Technology Co., Ltd. H81ND2H/H81ND2H, BIOS F3 08/11/2015 Oct 18 16:09:18 TestMachine kernel: [8.449135] 81901608 819015e6 c90004973d48 Oct 18 16:09:18 TestMachine kernel: [8.449139] 81742f0f 0007 81901608 c90004973d78 Oct 18 16:09:18 TestMachine kernel: [8.449141] 811cb706 8800d47359e0 c90004973ed8 Oct 18 16:09:18 TestMachine kernel: [8.449144] Call Trace: Oct 18 16:09:18 TestMachine kernel: [8.449151] [] dump_stack+0x4c/0x7f Oct 18 16:09:18 TestMachine kernel: [8.449154] [] report_size_overflow+0x36/0x40 Oct 18 16:09:18 TestMachine kernel: [8.449158] [] btrfs_real_readdir+0x69c/0x6d0 Oct 18 16:09:18 TestMachine kernel: [8.449160] [] iterate_dir+0xa8/0x150 Oct 18 16:09:18 TestMachine kernel: [8.449164] [] ? __fget_light+0x2d/0x70 Oct 18 16:09:18 TestMachine kernel: [8.449166] [] SyS_getdents+0xba/0x1c0 Oct 18 16:09:18 TestMachine kernel: [8.449169] [] ? iterate_dir+0x150/0x150 Oct 18 16:09:18 TestMachine kernel: [8.449173] [] entry_SYSCALL_64_fastpath+0x12/0x83 Oct 18 16:09:18 TestMachine kernel: [8.449230] Overflow: 7fff * Second bug: fs/btrfs/file.c:1871 Example--> Oct 18 16:09:20 TestMachine kernel: [ 10.526375] PAX: size overflow detected in function btrfs_sync_file fs/btrfs/file.c:1871 cicus.679_107 max, count: 289, decl: btrfs_wait_ordered_range; num: 3; context: fndecl; Oct 18 16:09:20 TestMachine kernel: [ 10.526380] CPU: 1 PID: 3160 Comm: mysqld Not tainted 4.2.3-grsec #1 Oct 18 16:09:20 TestMachine kernel: [ 10.526382] Hardware name: Gigabyte Technology Co., Ltd. H81ND2H/H81ND2H, BIOS F3 08/11/2015 Oct 18 16:09:20 TestMachine kernel: [ 10.526384] 819019e5 81901924 c90004d8bd98 Oct 18 16:09:20 TestMachine kernel: [ 10.526387] 81742f0f 88021f28ddc0 819019e5 c90004d8bdc8 Oct 18 16:09:20 TestMachine kernel: [ 10.526390] 811cb706 880202e9e270 8000 Oct 18 16:09:20 TestMachine kernel: [ 10.526392] Call Trace: Oct 18 16:09:20 TestMachine kernel: [ 10.526399] [] dump_stack+0x4c/0x7f Oct 18 16:09:20 TestMachine kernel: [ 10.526402] [] report_size_overflow+0x36/0x40 Oct 18 16:09:20 TestMachine kernel: [ 10.526404] [] btrfs_sync_file+0x90/0x490 Oct 18 16:09:20 TestMachine kernel: [ 10.526407] [] vfs_fsync_range+0x59/0xc0 Oct 18 16:09:20 TestMachine kernel: [ 10.526410] [] ? __fget_light+0x2d/0x70 Oct 18 16:09:20 TestMachine kernel: [ 10.526411] [] do_fsync+0x3c/0x70 Oct 18 16:09:20 TestMachine kernel: [ 10.526413] [] SyS_fsync+0x15/0x30 Oct 18 16:09:20 TestMachine kernel: [ 10.526415] [] entry_SYSCALL_64_fastpath+0x12/0x83 * len = end - start + 1 vfs_fsync calls vfs_fsync_range with 0 and LLONG_MAX for start and end. In btrfs_sync_file the above expression causes a signed overflow (undefined behaviour) with these values. This is the whole dmesg http://pastebin.com/S9gjYpYX , thanks -- 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
Unclean shutdown, BTRFS will not mount after - what things to try in what order?
We have a Ubuntu 14.10 server that has a BTRFS root filesystem. There was a power outage, and the server will not boot afterwards. We went into rescue mode, and / didn't mount there, in the /var/log/syslog we see: BTRFS: read error corrected: ino 1 of 398856193 (dev /dev/sda1 sector 795400) repeated twice more with different innodes and sectors parent transid verify failed on 397688832 wanted 901 found 408 repeated once more with different numbers BTRFS: Failed to read block groups: -5 rescue: mount: mounting /dev/sda1 on /target failed: Invalid argument rescue-mode: mount '/dev/sda1' /target failed BTRFS: open_ctree failed I've been reading through pages like https://btrfs.wiki.kernel.org/index.php/Problem_FAQ, and apparently there's a few things to try (e.g. mounting with -o recovery, btrfs-zero-log etc), and also using btrfs-restore. However, I'm wondering if the above specific error messages shed any light on what happened? Is there any metadata, or anything I can grab from the disks which would help diagnose it? -- 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 root filesystem and large discrepancy between du (73Gb used) and df (125 Gb used)?
Hi, I have a Ubuntu 14.04 Server host using BTRFS that seems to show large discrepancies between the output of du (73 GB used) and df (125 GB used). The hardware is a HP DL360 G5 with two 73 GB SAS drives running in RAID0 (yes, I know...). Basically, I'm running out of space on the root (/) filesystem, and I can't work out why. Output of df: $ df -h Filesystem Size Used Avail Use% Mounted on /dev/cciss/c0d0p1 135G 125G 9.3G 94% / none 4.0K 0 4.0K 0% /sys/fs/cgroup udev 990M 4.0K 990M 1% /dev tmpfs 200M 1.9M 199M 1% /run none 5.0M 0 5.0M 0% /run/lock none 1000M 0 1000M 0% /run/shm none 100M 0 100M 0% /run/user /dev/cciss/c0d0p1 135G 125G 9.3G 94% /home Output of du: $ sudo du -chs * 9.7M bin 174M boot 4.0K dev 8.3M etc 5.4G home 4.0K initrd.img 4.0K initrd.img.old 1.2G lib 4.0K lib64 0 media 0 mnt 0 opt du: cannot access ‘proc/14648/task/14648/fd/4’: No such file or directory du: cannot access ‘proc/14648/task/14648/fdinfo/4’: No such file or directory du: cannot access ‘proc/14648/fd/4’: No such file or directory du: cannot access ‘proc/14648/fdinfo/4’: No such file or directory 0 proc 8.0K root 1.9M run 13M sbin 36G srv 0 sys 4.0K system.properties 48K tmp 1.5G usr 28G var 4.0K vmlinuz 4.0K vmlinuz.old 73G total Output of mount: $ mount /dev/cciss/c0d0p1 on / type btrfs (rw,relatime,subvol=@) proc on /proc type proc (rw,noexec,nosuid,nodev) sysfs on /sys type sysfs (rw,noexec,nosuid,nodev) none on /sys/fs/cgroup type tmpfs (rw) none on /sys/fs/fuse/connections type fusectl (rw) none on /sys/kernel/debug type debugfs (rw) none on /sys/kernel/security type securityfs (rw) udev on /dev type devtmpfs (rw,mode=0755) devpts on /dev/pts type devpts (rw,noexec,nosuid,gid=5,mode=0620) tmpfs on /run type tmpfs (rw,noexec,nosuid,size=10%,mode=0755) none on /run/lock type tmpfs (rw,noexec,nosuid,nodev,size=5242880) none on /run/shm type tmpfs (rw,nosuid,nodev) none on /run/user type tmpfs (rw,noexec,nosuid,nodev,size=104857600,mode=0755) none on /sys/fs/pstore type pstore (rw) cgroup on /sys/fs/cgroup/cpuset type cgroup (rw,relatime,cpuset) cgroup on /sys/fs/cgroup/cpu type cgroup (rw,relatime,cpu) cgroup on /sys/fs/cgroup/cpuacct type cgroup (rw,relatime,cpuacct) cgroup on /sys/fs/cgroup/memory type cgroup (rw,relatime,memory) cgroup on /sys/fs/cgroup/devices type cgroup (rw,relatime,devices) cgroup on /sys/fs/cgroup/freezer type cgroup (rw,relatime,freezer) cgroup on /sys/fs/cgroup/blkio type cgroup (rw,relatime,blkio) cgroup on /sys/fs/cgroup/perf_event type cgroup (rw,relatime,perf_event) cgroup on /sys/fs/cgroup/hugetlb type cgroup (rw,relatime,hugetlb) /dev/cciss/c0d0p1 on /home type btrfs (rw,relatime,subvol=@home) systemd on /sys/fs/cgroup/systemd type cgroup (rw,noexec,nosuid,nodev,none,name=systemd) Contents of /etc/fstab: $ cat /etc/fstab # /etc/fstab: static file system information. # # Use 'blkid' to print the universally unique identifier for a # device; this may be used with UUID= as a more robust way to name devices # that works even if disks are added and removed. See fstab(5). # # file system mount point type options dump pass # / was on /dev/cciss/c0d0p1 during installation UUID=d1fac2b3-63dc-4b60-a8d2-1ac7a38187f7 / btrfs relatime,subvol=@ 0 1 # /home was on /dev/cciss/c0d0p1 during installation UUID=d1fac2b3-63dc-4b60-a8d2-1ac7a38187f7 /home btrfs relatime,subvol=@home 0 2 # swap was on /dev/cciss/c0d0p5 during installation UUID=119e00c3-6b4f-49aa-b5b0-4736d5398c28 noneswapsw 0 0 Output of lsblk: $ lsblk NAME MAJ:MIN RM SIZE RO TYPE MOUNTPOINT cciss!c0d0 104:00 136.7G 0 disk ├─cciss!c0d0p1 104:10 134.7G 0 part ├─cciss!c0d0p2 104:20 1K 0 part └─cciss!c0d0p5 104:50 2G 0 part Contents of /proc/partitions: $ cat /proc/partitions major minor #blocks name 1040 143305920 cciss/c0d0 1041 141209600 cciss/c0d0p1 1042 1 cciss/c0d0p2 10452094080 cciss/c0d0p5 Output of btrfs fi df: $ sudo btrfs fi df / [sudo] password for victorhooi: Data, single: total=132.64GiB, used=122.88GiB System, DUP: total=8.00MiB, used=20.00KiB System, single: total=4.00MiB, used=0.00 Metadata, DUP: total=1.00GiB, used=700.39MiB Metadata, single: total=8.00MiB, used=0.00 lsof shows a single deleted file currently: $ sudo lsof | grep deleted init 1 root9w REG 0,19 1962173841 /var/log/upstart/systemd-logind.log.1 (deleted) Any thoughts on what might be going on? Regards, Victor -- 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: Issues with KVM
On 22/07/2011 21:59, C Anthony Risinger wrote: is the disk's cache mode set to none [or maybe writeback] (virtmanager)? I tested various options: the most important is the cache mode. cache=none is a little bit better than cache=default (writethrough), but there is an huge difference using cache=unsafe. This option is not supported by virt-manager, but by kvm. Using cache=unsafe, the installation of FreeBSD is ~100x faster: - cache=default: write at 1 to 8 KB/sec - cache=none: write at 40 KB/sec - cache=unsafe: write at 1200 KB/sec According to agraf__ on IRC (#kvm on FreeNode), the cache mode has the following effect: - cache=writethrough calls fsync() after every write() - cache=none uses O_DIRECT - cache=writeback calls fsync() when the guest issues a barrier() (don't use O_DIRECT) - cache=unsafe doesn't do any fsync() (but don't use O_DIRECT) I still have to test writeback ;-) I found another mail thread, of last summer (July 2010), which is exactly the same problem that I had: BTRFS: Unbelievably slow with kvm/qemu on this mailing list. It contains another advice: Make sure you build your file system with mkfs.btrfs -m single -d single /dev/whatever. You may well be writing duplicate copies of everything. http://lkml.org/lkml/2010/7/12/5 -- FreeBSD installation in VirtualBox is as fast (or maybe a little bit slower) than the installation in kvm using cache=unsafe. I suppose that VirtualBox uses something like cache=unsafe or cache=writeback. Victor -- 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: Issues with KVM
Hi, Le 22/07/2011 21:59, C Anthony Risinger a écrit : ) is the host FS btrfs? The host (Fedora) FS is btrfs, the VM (Debian) uses ext4 (or maybe ext3, I will have to check). ) are virtio modules in the initramfs (or kernel probably)? ) are you sure virtio is being used (eg. are the disks called vdX vs sdX)? ) is the disk bus set to virtio (virtmanager)? I'm not sure. I will have to check. ) is the disk's cache mode set to none [or maybe writeback] (virtmanager)? I don't remember, I will check. What is the effect of this option? (What is the effect on the host FS (btrfs)?) ) is the disk's storage format set to raw, should be (virtmanager)? Yes, the image type is raw. ) is caching enabled on the image? () What do you mean? Is it possible to enable or disable the cache on a specific file on the host (Fedora, btrfs)? Or you mean set cache to none in the configuration of the VM? probably need to change the cache mode on the disk, or if the host is btrfs you need to flag the image with whetever is needed to prevent continuous COWing. Can nodatacow option of btrfs have an effect on this issue? Is it possible to set this option for a specific file or directory? Victor PS: I have subscribed to the mailing list. PS2: I'm not at home this week-end, I will check monday. -- 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
Issues with KVM
Hi, I have a new fast computer to run many virtual machines. Everything looks very fast, except the installation of new operating systems in KVM. The installation is very fast until it begins to write on disk. It looks like it writes slower and slower. I tried Debian, FreeBSD, OpenIndiana and OpenBSD: same problem. The FreeBSD installer displays the speed: it starts at 780 KB/sec (which it already very slow) to finish between 1 and 8 KB/sec. darksatanic suggested me to use nodatacow mount flag: it is not faster, and it looks even slower (fewer wsec/s in iostat output, see below). The computer is an Intel i7 2600 (4 cores with hyper threading: 8 threads), 12 GB or RAM, 2 hard drives of 1 TB (Western Digital Caviar Blue 1 To 7200 RPM 32 Mo Serial ATA 6Gb/s - WD10EALX). Both disks are connected to SATA 6 GB/sec connectors using a P67 chipset. I'm using RAID 0 with Linux software (MD) RAID, and I have one unique btrfs partition of 2 TB. The host OS is Fedora 15 (Linux kernel 2.6.38). I'm using hardware virtualisation with KVM. Debian is installed using virtio, so it should not be an issue with the hard drive driver of KVM. I'm watching iostat during the Debian installation. With the default mount option, wsec/s starts at 49000 to finish near 42000 (on the MD device), %usage is greater than 50% of both disks (near 80% for sda, near 60% for sdb). Using nodatacow option, wsec/s starts at 12000 (%usage 75%) to finish near 1 (%usage always 75%). It is slower, right? A sector is 512 bytes. The Debian image size is 40 GB, its type is raw. The system load is greater than 2 (or maybe 3) during the installation of the VM, while CPU usage is under 8% and wa% is also low (maybe 10% or lower, I don't remember). bonnie++ output (on the Fedora host, not in a VM): Version 1.96 --Sequential Output-- --Sequential Input- --Random- Concurrency 1 -Per Chr- --Block-- -Rewrite- -Per Chr- --Block-- --Seeks-- MachineSize K/sec %CP K/sec %CP K/sec %CP K/sec %CP K/sec %CP /sec %CP ned 24048M 346 98 220839 24 98489 19 245 84 251547 18 199.2 259 Latency 37256us 326ms 943ms 251ms 197ms 151ms Version 1.96 --Sequential Create-- Random Create ned -Create-- --Read--- -Delete-- -Create-- --Read--- -Delete-- files /sec %CP /sec %CP /sec %CP /sec %CP /sec %CP /sec %CP 16 11128 34 + +++ 16558 45 14006 40 + +++ 17226 48 Latency 14997us 663us 11401us8115us 282us 10105us 1.96,1.96,ned,1,1311365747,24048M,,346,98,220839,24,98489,19,245,84,251547,18,199.2,259,16,11128,34,+,+++,16558,45,14006,40,+,+++,17226,48,37256us,326ms,943ms,251ms,197ms,151ms,14997us,663us,11401us,8115us,282us,10105us Do you have any idea why the %usage is so high (in iostat), while the speed looks so low? The disk speed during the installation is between 5 MB/sec and 23 MB/sec, whereas the raw speed is greater than 200 MB/sec on the host (234 MB/sec according to hdparm -t /dev/md127, 220 MB/sec according to bonnie++ on sequential output). It's difficult to read bonnie++ output: random create is near 14 MB/sec if I read correctly. btrfs behaves maybe very badly with a raw image of 40 GB, especially on RAID 0 with 2 disks? Should I try other KVM option (e.g. use another type of image)? Try btrfs RAID instead of Linux MD RAID? Try to disable some CPU cores? Or maybe not using btrfs for KVM images? :-) Victor -- 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 device scan
I have a couple computers running 2.6.38 (Ubuntu Natty 2.6.38-8-generic), and on both of them btrfs device scan comes back with nothing other than failed to read /dev/sr0 One computer has a btrfs RAID-1 volume, and the other has two separate btrfs filesystems. The results are the same whether the filesystems are mounted or not. Why is btrfs device scan not scanning the devices? vic -- 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 device scan
On 05/12/2011 12:46 PM, Helmut Hullen wrote: Hallo, Victor, Du meintest am 12.05.11: I have a couple computers running 2.6.38 (Ubuntu Natty 2.6.38-8-generic), and on both of them btrfs device scan comes back with nothing other than failed to read /dev/sr0 What tells ls /dev/sd* ls /dev/md* $ ls /dev/sd* /dev/sda /dev/sda1 /dev/sda2 /dev/sda5 /dev/sdb /dev/sdb1 /dev/sdc /dev/sdc1 $ ls /dev/md* ls: cannot access /dev/md*: No such file or directory $ btrfs device scan Scanning for Btrfs filesystems failed to read /dev/sr0 $ btrfs filesystem show failed to read /dev/sr0 Label: 'server-backup' uuid: b927ead9-2e5b-4ee8-b9f4-7209177c49d8 Total devices 2 FS bytes used 603.17GB devid1 size 1.36TB used 605.28GB path /dev/sdb1 devid2 size 1.36TB used 605.26GB path /dev/sdc1 Btrfs Btrfs v0.19 $ -- 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
OSX Support/Driver?
Hi, I just purchased my very first Mac, a 2011 Macbook Pro yesterday. Now, I am intending to dualboot with OSX and Arch Linux on it, however, I'd also be interested in accessing my BTRFSfilesystems from under OSX. I noticed that the btrfs-utils themselves seem to be in Macports: http://www.macports.org/ports.php?by=namesubstr=btrfs However, there doesn't seem to be any support in the OSX kernel itself for BTRFS. Is such support completely out of the question? Possibility of a FUSE driver? Or are there technical impediments to either option? Cheers, Victor -- 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 testing
] btrfs_relocate_chunk+0x65/0x4a2 [ 242.083930] [8114746c] ? map_extent_buffer+0x67/0xa1 [ 242.083940] [81143c38] ? pagefault_enable+0x23/0x2e [ 242.083949] [811474af] ? unmap_extent_buffer+0x9/0xb [ 242.083958] [8113cd74] ? btrfs_dev_extent_chunk_offset+0xb6/0xc6 [ 242.083969] [8114ad14] btrfs_shrink_device+0x1ce/0x2f1 [ 242.083980] [8114c7f9] btrfs_rm_device+0x210/0x4aa [ 242.083989] [81150b88] ? btrfs_ioctl+0x60c/0x7d0 [ 242.084000] [8109db7a] ? copy_from_user+0x9/0xb [ 242.084010] [81150baa] btrfs_ioctl+0x62e/0x7d0 [ 242.084022] [810ca834] vfs_ioctl+0x31/0xa2 [ 242.084032] [810cb150] do_vfs_ioctl+0x457/0x48a [ 242.084042] [810cb1d4] sys_ioctl+0x51/0x75 [ 242.084053] [8100212b] system_call_fastpath+0x16/0x1b [ 242.084059] Code: 00 00 01 74 05 e8 28 e9 13 00 c9 c3 55 48 89 e5 f0 ff 07 c9 c3 55 48 89 e5 f0 81 07 00 00 00 01 c9 c3 55 b8 00 01 00 00 48 89 e5 f0 66 0f c1 07 38 e0 74 06 f3 90 8a 07 eb f6 c9 c3 55 48 89 e5 [ 242.084155] RIP [81060c79] do_raw_spin_lock+0x9/0x1a [ 242.084165] RSP 88010ca13508 [ 242.084170] CR2: 00b8 [ 242.084177] ---[ end trace 368ef32f0f0e8e74 ]--- [ 242.084184] note: btrfs[4119] exited with preempt_count 1 [r...@studio-arch ~]# What to do to fix? -- Victor Lowther LPIC2 UCP RHCE -- 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 - Unable to mount, can't read superblock?
Taruisi, Thanks for that. I can't believe it was something as simple as that. It's a laptop, so normally I suspend, But yeah, I've tried rebooting since (actually before your message - but thanks anyway), and it's all good now. Seriously gave me a bit of a shock there. Yes, I know, btrfs isn't stable, but I nearly thought it all went like that, poof *touch wood* =). I guess I wasn't used to it not re-mounting after that after an unplug event. Do you know if there's a timeline for device file renaming? I suppose it's not that big a deal now that I'm aware it's not supported. Thanks again for your advice. Cheers, Victor On 15 February 2010 11:28, TARUISI Hiroaki taruishi.hir...@jp.fujitsu.com wrote: Hi, This disk was used as /dev/sdd previously, and now it's named /dev/sdc, isn't it? If so, you can use this usb disk after reboot, or adjusting that the disk is recognized as /dev/sdd. Btrfs does not support device file renaming yet. Regards, taruisi (2010/02/13 21:45), Victor Hooi wrote: heya, This is on kernel 2.6.32.8-1, on Arch Linux 64-bit. I have an external harddisk, with a btrfs filessystem on it. Just now, after a reboot, I seem to be unable to mount it. KDE gives a message about being unable to find the superblock, trying to mount it from the command-line gives something similar: mount: /dev/sdc1: can't read superblock I do know the last time I used the disk, it may not have been unmounted cleanly. Could that have caused this current issue? Any possible remedy? I'm really hoping it is, because that's a 1.5 Tb external disk...lol. Also, dmesg contains: usb 2-2: new high speed USB device using ehci_hcd and address 8 usb 2-2: configuration #1 chosen from 1 choice scsi10 : SCSI emulation for USB Mass Storage devices usb-storage: device found at 8 usb-storage: waiting for device to settle before scanning scsi 10:0:0:0: Direct-Access WDC WD15 EADS-00P8B0 PQ: 0 ANSI: 2 sd 10:0:0:0: Attached scsi generic sg2 type 0 usb-storage: device scan complete sd 10:0:0:0: [sdc] 2930277168 512-byte logical blocks: (1.50 TB/1.36 TiB) sd 10:0:0:0: [sdc] Write Protect is off sd 10:0:0:0: [sdc] Mode Sense: 38 00 00 00 sd 10:0:0:0: [sdc] Assuming drive cache: write through sd 10:0:0:0: [sdc] Assuming drive cache: write through sdc: sdc1 sd 10:0:0:0: [sdc] Assuming drive cache: write through sd 10:0:0:0: [sdc] Attached SCSI disk device label tessier-ashpool devid 1 transid 4882 /dev/sdc1 open /dev/sdd1 failed Cheers, Victor -- 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
