* External USB-SATA bridge rewriting logical block sizes
@ 2014-03-03 5:02 Jan Kundrát
2014-03-03 14:26 ` Stan Hoeppner
0 siblings, 1 reply; 4+ messages in thread
From: Jan Kundrát @ 2014-03-03 5:02 UTC (permalink / raw)
To: linux-raid
Hi,
I'm having troubles using WD40EZRX [1] in a USB3 -> SATA dock. The trouble
I'm hitting is that the data I get back when reading the first partition
differ depending on whether I access the drive via the enclosure, or
directly as a SATA disk.
Here is how it looks directly attached:
plejtvak ~ # sg_readcap -l /dev/sdc
Read Capacity results:
Protection: prot_en=0, p_type=0, p_i_exponent=0
Logical block provisioning: lbpme=0, lbprz=0
Last logical block address=7814037167 (0x1d1c0beaf), Number of logical
blocks=7814037168
Logical block length=512 bytes
Logical blocks per physical block exponent=3
Lowest aligned logical block address=0
Hence:
Device size: 4000787030016 bytes, 3815447.8 MiB, 4000.79 GB
And this is how it looks through the USB convertor:
svist ~ # sg_readcap -l /dev/sdb
Read Capacity results:
Protection: prot_en=0, p_type=0, p_i_exponent=0
Logical block provisioning: lbpme=0, lbprz=0
Last logical block address=976754645 (0x3a3817d5), Number of logical
blocks=976754646
Logical block length=4096 bytes
Logical blocks per physical block exponent=0
Lowest aligned logical block address=0
Hence:
Device size: 4000787030016 bytes, 3815447.8 MiB, 4000.79 GB
My partition table is probably borked -- IIRC I created it via `cfdisk`
over the USB connection, but I am not sure about that anymore. This is what
gdisk reports when directly attached:
Command (? for help): p
Disk /dev/sdc: 7814037168 sectors, 3.6 TiB
Logical sector size: 512 bytes
Disk identifier (GUID): AD1C809E-45FC-4CDD-A9EC-2855D4AF1E6E
Partition table holds up to 128 entries
First usable sector is 34, last usable sector is 7814037134
Partitions will be aligned on 8-sector boundaries
Total free space is 4294972395 sectors (2.0 TiB)
Number Start (sector) End (sector) Size Code Name
1 63 3519064768 1.6 TiB 0700 Linux/Windows data
...and through the USB dock:
Command (? for help): p
Disk /dev/sdb: 976754646 sectors, 3.6 TiB
Logical sector size: 4096 bytes
Disk identifier (GUID): DFE2C96D-8A4C-4516-86B2-4F6DA0EB8609
Partition table holds up to 128 entries
First usable sector is 6, last usable sector is 976754640
Partitions will be aligned on 8-sector boundaries
Total free space is 57 sectors (228.0 KiB)
Number Start (sector) End (sector) Size Code Name
1 63 3519064768 13.1 TiB 8300 Linux filesystem
I have a filesystem on the first partition. Accessing it works fine via the
USB reduction, but mount refuses to proceed when accessing the SATA disk
directly. I assume that this is because the partition starts at byte
(63*4096) from the beginning of the disk, which matches the detected
partition start when using the USB thingy. However, when accessing the disk
directly over SATA, the partition is presumably expected to begin at
(63*512), which is a very different location, and stuff therefore breaks.
I have already read the discussion from January [3] and believe that this
is a different situation -- I haven't disassembled anything, this is a
standalone USB->SATA convertor and a standalone SATA disk.
I would appreciate a couple of pointers here:
- Did I screw up somehow? If so, how? Perhaps by using wrong partition
table layout, i.e. by tying myself to logical blocks?
- Can I salvage the data by rewriting the partition table in some magic way
which would work with both "physical 4k, logic 4k" and "physical 512, logic
4k" modes at the same time?
- Is the USB enclosure which I'm using just a crappy piece of hardware that
I should stay away from?
- What is the cleanest way of accessing the drive in the safest possible
manner? I would like to put my backups in there, and I wasn't really happy
when I plugged the drive directly in order to test the contents and found
out that it won't even mount.
- I guess I could just give up on partitioning altogether and use
filesystem on the whole device without much trouble. However, I'm afraid
that this might confuse the kernel's partition layout detection, and it
also seems a bit ugly.
Help is much appreciated. There's an unsolved Stackoverflow post at [4]
which appears to be dealing with the exactly same problem, btw.
With kind regards,
Jan
[1] WD40EZRX-00SPEB0, a 4TB WD Green
[2] "174c:5106 ASMedia Technology Inc. Transcend StoreJet 25M3" (lsusb),
also known as "IcyBox IB-116StU3-B" (label)
[3] http://www.spinics.net/lists/raid/msg45555.html
[4]
http://superuser.com/questions/679725/how-to-correct-512-byte-sector-mbr-on-a-4096-byte-sector-disk
--
Trojitá, a fast Qt IMAP e-mail client -- http://trojita.flaska.net/
--
To unsubscribe from this list: send the line "unsubscribe linux-raid" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply [flat|nested] 4+ messages in thread
* Re: External USB-SATA bridge rewriting logical block sizes
2014-03-03 5:02 External USB-SATA bridge rewriting logical block sizes Jan Kundrát
@ 2014-03-03 14:26 ` Stan Hoeppner
2014-03-03 15:18 ` Jan Kundrát
0 siblings, 1 reply; 4+ messages in thread
From: Stan Hoeppner @ 2014-03-03 14:26 UTC (permalink / raw)
To: Jan Kundrát, linux-raid
On 3/2/2014 11:02 PM, Jan Kundrát wrote:
> Hi,
> I'm having troubles using WD40EZRX [1] in a USB3 -> SATA dock. The
> trouble I'm hitting is that the data I get back when reading the first
> partition differ depending on whether I access the drive via the
> enclosure, or directly as a SATA disk.
>
> Here is how it looks directly attached:
>
> plejtvak ~ # sg_readcap -l /dev/sdc
> Read Capacity results:
> Protection: prot_en=0, p_type=0, p_i_exponent=0
> Logical block provisioning: lbpme=0, lbprz=0
> Last logical block address=7814037167 (0x1d1c0beaf), Number of logical
> blocks=7814037168
> Logical block length=512 bytes
> Logical blocks per physical block exponent=3
> Lowest aligned logical block address=0
> Hence:
> Device size: 4000787030016 bytes, 3815447.8 MiB, 4000.79 GB
>
> And this is how it looks through the USB convertor:
>
> svist ~ # sg_readcap -l /dev/sdb
> Read Capacity results:
> Protection: prot_en=0, p_type=0, p_i_exponent=0
> Logical block provisioning: lbpme=0, lbprz=0
> Last logical block address=976754645 (0x3a3817d5), Number of logical
> blocks=976754646
> Logical block length=4096 bytes
> Logical blocks per physical block exponent=0
> Lowest aligned logical block address=0
> Hence:
> Device size: 4000787030016 bytes, 3815447.8 MiB, 4000.79 GB
>
> My partition table is probably borked -- IIRC I created it via `cfdisk`
> over the USB connection, but I am not sure about that anymore. This is
> what gdisk reports when directly attached:
>
> Command (? for help): p
> Disk /dev/sdc: 7814037168 sectors, 3.6 TiB
> Logical sector size: 512 bytes
> Disk identifier (GUID): AD1C809E-45FC-4CDD-A9EC-2855D4AF1E6E
> Partition table holds up to 128 entries
> First usable sector is 34, last usable sector is 7814037134
> Partitions will be aligned on 8-sector boundaries
> Total free space is 4294972395 sectors (2.0 TiB)
>
> Number Start (sector) End (sector) Size Code Name
> 1 63 3519064768 1.6 TiB 0700 Linux/Windows data
>
> ...and through the USB dock:
>
> Command (? for help): p
> Disk /dev/sdb: 976754646 sectors, 3.6 TiB
> Logical sector size: 4096 bytes
> Disk identifier (GUID): DFE2C96D-8A4C-4516-86B2-4F6DA0EB8609
> Partition table holds up to 128 entries
> First usable sector is 6, last usable sector is 976754640
> Partitions will be aligned on 8-sector boundaries
> Total free space is 57 sectors (228.0 KiB)
>
> Number Start (sector) End (sector) Size Code Name
> 1 63 3519064768 13.1 TiB 8300 Linux filesystem
>
> I have a filesystem on the first partition. Accessing it works fine via
> the USB reduction, but mount refuses to proceed when accessing the SATA
> disk directly. I assume that this is because the partition starts at
> byte (63*4096) from the beginning of the disk, which matches the
> detected partition start when using the USB thingy. However, when
> accessing the disk directly over SATA, the partition is presumably
> expected to begin at (63*512), which is a very different location, and
> stuff therefore breaks.
>
> I have already read the discussion from January [3] and believe that
> this is a different situation -- I haven't disassembled anything, this
> is a standalone USB->SATA convertor and a standalone SATA disk.
>
> I would appreciate a couple of pointers here:
>
> - Did I screw up somehow? If so, how?
Yes.
> - Can I salvage the data by rewriting the partition table in some magic
> way which would work with both "physical 4k, logic 4k" and "physical
> 512, logic 4k" modes at the same time?
Presumably you have some md raid level with fault tolerance, since you
posted this to the linux-raid list. Why not simply kick the drive from
the array, install it "direct" inside the chassis, repartition it the
same as the other members of the array that are direct connected to the
SATA controller, re-add the partition to the array, and rebuild.
> - Is the USB enclosure which I'm using just a crappy piece of hardware
> that I should stay away from?
All USB drive enclosures are crap. Why you prepped this drive in it
with intention of moving it into the PC chassis leaves me scratching my
head. Is this some habit you developed years ago? Prepping a new drive
in a USB before permanently installing it in the chassis? If so, I'd
recommend using a hot swap SATA chassis that installs in a 5.25" drive
bay instead. They're $15-30 USD, cheaper, and more reliable, than a USB
dock, by far.
Never use USB connected disk drives for RAID. This is but one of many
problems you'll run into.
> - What is the cleanest way of accessing the drive in the safest possible
> manner? I would like to put my backups in there, and I wasn't really
> happy when I plugged the drive directly in order to test the contents
> and found out that it won't even mount.
See above.
> - I guess I could just give up on partitioning altogether and use
> filesystem on the whole device without much trouble. However, I'm afraid
> that this might confuse the kernel's partition layout detection, and it
> also seems a bit ugly.
The problem isn't use of partitions, but use a USB.
> Help is much appreciated.
Cheers.
--
Stan
--
To unsubscribe from this list: send the line "unsubscribe linux-raid" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply [flat|nested] 4+ messages in thread
* Re: External USB-SATA bridge rewriting logical block sizes
2014-03-03 14:26 ` Stan Hoeppner
@ 2014-03-03 15:18 ` Jan Kundrát
2014-03-04 6:36 ` Stan Hoeppner
0 siblings, 1 reply; 4+ messages in thread
From: Jan Kundrát @ 2014-03-03 15:18 UTC (permalink / raw)
To: Stan Hoeppner; +Cc: linux-raid
On Monday, 3 March 2014 15:26:24 CEST, Stan Hoeppner wrote:
> Presumably you have some md raid level with fault tolerance, since you
> posted this to the linux-raid list. Why not simply kick the drive from
> the array, install it "direct" inside the chassis, repartition it the
> same as the other members of the array that are direct connected to the
> SATA controller, re-add the partition to the array, and rebuild.
Hi Stan, I don't run RAID on these machines. I saw a recent thread dealing
with 4k drives on this ML which made me hope that this topic won't be
considered OT here. Sorry if this is not appropriate -- do you happen to
know a more suitable ML?
> Why you prepped this drive in it with intention of moving it into the PC
> chassis leaves me scratching my head.
My primary machine is a T420s laptop which has a USB3 port, but no eSATA.
The throughput I can get from a drive attached there is much better than
what I can get via network from my other box with plenty of SATA ports, but
only a VIA C7 CPU (even though it has a gigabit NIC). Expected, I guess.
Another aspect is energy saving -- the tiny power plug which comes with the
USB dock eats less than the other PC.
> Is this some habit you developed years ago? Prepping a new drive
> in a USB before permanently installing it in the chassis? If so, I'd
> recommend using a hot swap SATA chassis that installs in a 5.25" drive
> bay instead. They're $15-30 USD, cheaper, and more reliable, than a USB
> dock, by far.
Yes, that's what I use for the direct connection. 100% passive, very
reliable, appears to be robust, mechanically. However, I cannot connect
that to the laptop where I do most of my work. I do have a dock, so it's
very convenient and ergonomic, but the IO options are a bit limited on this
model.
Cheers,
Jan
--
Trojitá, a fast Qt IMAP e-mail client -- http://trojita.flaska.net/
--
To unsubscribe from this list: send the line "unsubscribe linux-raid" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply [flat|nested] 4+ messages in thread
* Re: External USB-SATA bridge rewriting logical block sizes
2014-03-03 15:18 ` Jan Kundrát
@ 2014-03-04 6:36 ` Stan Hoeppner
0 siblings, 0 replies; 4+ messages in thread
From: Stan Hoeppner @ 2014-03-04 6:36 UTC (permalink / raw)
To: Jan Kundrát; +Cc: linux-raid
On 3/3/2014 9:18 AM, Jan Kundrát wrote:
> On Monday, 3 March 2014 15:26:24 CEST, Stan Hoeppner wrote:
>> Presumably you have some md raid level with fault tolerance, since you
>> posted this to the linux-raid list. Why not simply kick the drive from
>> the array, install it "direct" inside the chassis, repartition it the
>> same as the other members of the array that are direct connected to the
>> SATA controller, re-add the partition to the array, and rebuild.
>
> Hi Stan, I don't run RAID on these machines. I saw a recent thread
> dealing with 4k drives on this ML which made me hope that this topic
> won't be considered OT here. Sorry if this is not appropriate -- do you
> happen to know a more suitable ML?
Such an issue should be discussed on either of these two lists:
linux-ide@vger.kernel.org
linux-usb@vger.kernel.org
http://vger.kernel.org/vger-lists.html
>> Why you prepped this drive in it with intention of moving it into the
>> PC chassis leaves me scratching my head.
>
> My primary machine is a T420s laptop which has a USB3 port, but no
> eSATA. The throughput I can get from a drive attached there is much
> better than what I can get via network from my other box with plenty of
> SATA ports, but only a VIA C7 CPU (even though it has a gigabit NIC).
> Expected, I guess.
So you simply want to be able to access this 4TB drive on both your
T420s and your VIA C7 based desktop/media PC. The solution to the
current problem is simple: plug the USB enclosure into one of the PC's
USB ports instead of plugging the bare drive into the SATA cage.
Logical sector size problem solved.
Now, if the C7 PC only has USB 2.0 ports and you demand more throughput
than the ~50MB/s this provides, USB 3.0 PCIe, mini PCIe, and PCI cards
are available. If your C7 system doesn't have any slots available, then
you're left with only one solution: acquire an eSATA ExpressCard/34 for
the T420s and an eSATA enclosure for the drive. This will give you 512B
sectors on both platforms and the maximum throughput of the drive.
However, you'll have to blow away the contents of the drive,
repartition, reformat, etc, since it was partitioned with 4096B logical
sector size being reported by the enclosure bridge chip.
...
>> Is this some habit you developed years ago? Prepping a new drive
>> in a USB before permanently installing it in the chassis? If so, I'd
>> recommend using a hot swap SATA chassis that installs in a 5.25" drive
>> bay instead. They're $15-30 USD, cheaper, and more reliable, than a USB
>> dock, by far.
>
> Yes, that's what I use for the direct connection. 100% passive, very
> reliable, appears to be robust, mechanically. However, I cannot connect
> that to the laptop where I do most of my work. I do have a dock, so it's
> very convenient and ergonomic, but the IO options are a bit limited on
> this model.
Sounds like an eSATA ExpressCard and eSATA enclosure are in your future.
Unless of course you have no way to get your data off the drive and
restore it after wiping the drive and starting over, in which case
you're stuck with USB 2.0 speed on the C7 box.
--
Stan
--
To unsubscribe from this list: send the line "unsubscribe linux-raid" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply [flat|nested] 4+ messages in thread
end of thread, other threads:[~2014-03-04 6:36 UTC | newest]
Thread overview: 4+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2014-03-03 5:02 External USB-SATA bridge rewriting logical block sizes Jan Kundrát
2014-03-03 14:26 ` Stan Hoeppner
2014-03-03 15:18 ` Jan Kundrát
2014-03-04 6:36 ` Stan Hoeppner
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.