All of lore.kernel.org
 help / color / mirror / Atom feed
From: Stan Hoeppner <stan@hardwarefreak.com>
To: "Jan Kundrát" <jkt@flaska.net>, linux-raid@vger.kernel.org
Subject: Re: External USB-SATA bridge rewriting logical block sizes
Date: Mon, 03 Mar 2014 08:26:24 -0600	[thread overview]
Message-ID: <53149110.7090008@hardwarefreak.com> (raw)
In-Reply-To: <f533c037-b72b-4039-9ef7-f2c61a0de3e6@flaska.net>

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

  reply	other threads:[~2014-03-03 14:26 UTC|newest]

Thread overview: 4+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2014-03-03  5:02 External USB-SATA bridge rewriting logical block sizes Jan Kundrát
2014-03-03 14:26 ` Stan Hoeppner [this message]
2014-03-03 15:18   ` Jan Kundrát
2014-03-04  6:36     ` Stan Hoeppner

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=53149110.7090008@hardwarefreak.com \
    --to=stan@hardwarefreak.com \
    --cc=jkt@flaska.net \
    --cc=linux-raid@vger.kernel.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
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.