1 |
Hi again |
2 |
|
3 |
This has been frustrating me ever since I bought the drive, but I have pushed |
4 |
off looking into it for a while. Part of the reason is that my desktop used to |
5 |
run pretty much 24/7 before I moved, so I rarely had to deal with this issue. |
6 |
However, now I'm more interested in not pointlessly wasting electricity and as |
7 |
such, encounter this issue at least once a day. Since my automatic backups run |
8 |
automatically if they were scheduled to run while the computer was off, this is |
9 |
becoming more and more annoying. |
10 |
|
11 |
What happens is that when I (cold) boot my desktop, my external Toshiba 3TB |
12 |
drive (which is always connected via USB3) is detected, but cannot mount. It |
13 |
*does* work once I unplug the USB3 plug and plug it back in. |
14 |
|
15 |
After finally getting around to debugging the issue, looking at the kernel log |
16 |
very quickly showed me what was happening: |
17 |
|
18 |
# journalctl -k -b -1 | grep "sdg" |
19 |
Mär 06 16:55:34 marcec kernel: sd 8:0:0:0: [sdg] Very big device. Trying to use READ CAPACITY(16). |
20 |
Mär 06 16:55:34 marcec kernel: sd 8:0:0:0: [sdg] 5860533160 512-byte logical blocks: (3.00 TB/2.72 TiB) |
21 |
Mär 06 16:55:34 marcec kernel: sd 8:0:0:0: [sdg] Write Protect is off |
22 |
Mär 06 16:55:34 marcec kernel: sd 8:0:0:0: [sdg] Mode Sense: 2b 00 00 00 |
23 |
Mär 06 16:55:34 marcec kernel: sd 8:0:0:0: [sdg] Write cache: disabled, read cache: enabled, doesn't support DPO or FUA |
24 |
Mär 06 16:55:34 marcec kernel: sd 8:0:0:0: [sdg] Very big device. Trying to use READ CAPACITY(16). |
25 |
Mär 06 16:55:20 marcec kernel: sdg: sdg1 sdg2 |
26 |
Mär 06 16:55:20 marcec kernel: sd 8:0:0:0: [sdg] Very big device. Trying to use READ CAPACITY(16). |
27 |
Mär 06 16:55:20 marcec kernel: sd 8:0:0:0: [sdg] Attached SCSI disk |
28 |
Mär 06 16:57:08 marcec kernel: sd 9:0:0:0: [sdg] Very big device. Trying to use READ CAPACITY(16). |
29 |
Mär 06 16:57:08 marcec kernel: sd 9:0:0:0: [sdg] 732566645 4096-byte logical blocks: (3.00 TB/2.72 TiB) |
30 |
Mär 06 16:57:08 marcec kernel: sd 9:0:0:0: [sdg] Write Protect is off |
31 |
Mär 06 16:57:08 marcec kernel: sd 9:0:0:0: [sdg] Mode Sense: 2b 00 00 00 |
32 |
Mär 06 16:57:08 marcec kernel: sd 9:0:0:0: [sdg] Write cache: disabled, read cache: enabled, doesn't support DPO or FUA |
33 |
Mär 06 16:57:08 marcec kernel: sd 9:0:0:0: [sdg] 732566645 4096-byte logical blocks: (3.00 TB/2.72 TiB) |
34 |
Mär 06 16:57:08 marcec kernel: sdg: sdg1 sdg2 |
35 |
Mär 06 16:57:08 marcec kernel: sdg: p1 size 10476524864 extends beyond EOD, enabling native capacity |
36 |
Mär 06 16:57:08 marcec kernel: sd 9:0:0:0: [sdg] 732566645 4096-byte logical blocks: (3.00 TB/2.72 TiB) |
37 |
Mär 06 16:57:08 marcec kernel: sdg: sdg1 sdg2 |
38 |
Mär 06 16:57:08 marcec kernel: sdg: p1 size 10476524864 extends beyond EOD, truncated |
39 |
Mär 06 16:57:08 marcec kernel: sd 9:0:0:0: [sdg] 732566645 4096-byte logical blocks: (3.00 TB/2.72 TiB) |
40 |
Mär 06 16:57:08 marcec kernel: sd 9:0:0:0: [sdg] Attached SCSI disk |
41 |
Mär 06 16:57:10 marcec kernel: BTRFS: device label MARCEC_BACKUP devid 1 transid 64138 /dev/sdg2 |
42 |
Mär 06 16:57:10 marcec kernel: BTRFS info (device sdg2): disk space caching is enabled |
43 |
Mär 06 16:57:17 marcec kernel: EXT4-fs (sdg1): mounted filesystem with ordered data mode. Opts: (null) |
44 |
|
45 |
(I rebooted in the meantime, and the drive is always detected correctly then, |
46 |
hence the "-b -1" argument to journalctl.) |
47 |
|
48 |
As you can see, the kernel initially thinks that it has 512-byte logical |
49 |
blocks. After unplugging the USB3 cable and plugging it back in it is |
50 |
detected as having 4096-byte logical blocks. From then on it works fine. |
51 |
|
52 |
The interesting question now is: *why* does this happen? According to [0] and |
53 |
[1], the problem is that the enclosure firmware is doing some silly block size |
54 |
translation in order to support MBR partitions, which apparently is done in a |
55 |
buggy fashion to boot. Sadly, they provide no solution. |
56 |
|
57 |
(I also can't help but wonder if that also helps explain the "p1 size |
58 |
10476524864 extends beyond EOD, truncated" messages. Note that the |
59 |
partitioning was done with gparted, but IIRC even editing it with cfdisk |
60 |
couldn't get rid of it.) |
61 |
|
62 |
I have not been able to find a way to fix this issue. The "manual" that comes |
63 |
with the drive is devoid of relevant information, and so far google comes up |
64 |
with several related posts, each without a solution. |
65 |
|
66 |
So, does anybody know of a way to get the drive to work more reliably? Or will |
67 |
I have to resort to a different enclosure (when I can afford it)? |
68 |
|
69 |
[0] http://askubuntu.com/questions/337017/cant-read-partition-table-of-3tb-usb-disk |
70 |
[1] http://ubuntuforums.org/showthread.php?t=1536933 |
71 |
|
72 |
Greetings, |
73 |
-- |
74 |
Marc Joliet |
75 |
-- |
76 |
"People who think they know everything really annoy those of us who know we |
77 |
don't" - Bjarne Stroustrup |