Formatting A USB Drive

Home » CentOS » Formatting A USB Drive
CentOS 17 Comments

Hi All,

I have a Drobo, connected to a CentOS 6.4 box. The box sees it as /dev/sdg.

I want to format it ext3 (as they dont support ext4) but when I try I get:

# fdisk -u /dev/sdg

WARNING: GPT (GUID Partition Table) detected on ‘/dev/sdg’! The util fdisk doesn’t support GPT. Use GNU Parted.

WARNING: The size of this disk is 17.6 TB (17592186044416 bytes). DOS partition table format can not be used on drives for volumes larger than (2199023255040 bytes) for 512-byte sectors. Use parted(1) and GUID
partition table format (GPT).

WARNING: DOS-compatible mode is deprecated. It’s strongly recommended to
switch off the mode (command ‘c’).

So I run:
# parted GNU Parted 2.1
Using /dev/sda Welcome to GNU Parted! Type ‘help’ to view a list of commands.
(parted) select /dev/sdg Using /dev/sdg
(parted) print Model: DROBO DroboPro (scsi)
Disk /dev/sdg: 17.6TB
Sector size (logical/physical): 512B/512B
Partition Table: gpt

Number Start End Size File system Name Flags


and looking at an example of creating a partition: (parted) mkpart primary
106 16179

I dont know what to do next since I dont see any partitions listed. I dont know what do to for the start and end point, although the man page says
“size in MB”. Do I just say 0 to (and convert 16.0TB to MB? Yes, I know it says 17.6 TB but this model drobo can only support partitions up to 16tb without making a second partition.

Can anyone provide some advice on that I am missing conceptually?


17 thoughts on - Formatting A USB Drive

  • If you have a GUI desktop installed you can install the gparted package from EPEL. It is easier to use than raw parted and mkfs.

  • So far, when I’ve been in that situation I’ve installed X, the gnome desktop, and the freenx package and connected from an NX client. Seemed easier then dealing with the parted options….

  • Jason T. Slack-Moehrle wrote:

    Several issues. First, if you use 4k blocks, the max filesystem size for ext3 is 16TB (see wikipedia on ext3). Second, I can’t remember where, but on some filesystem tool’s manpage, I read that the tools have problems going over 16TB. Third, fsck on a 16TB filesystem will take *days*, literally. I’m setting up, right now, a humongous RAID box, and I’ll probably be divvying up the 42TB (mirrored!) as 3 14TB filesystems, and they’re going to be ext4.


  • I found an article that led me to do:

    (parted) mkpart primary 0GB 16TB
    (parted) print Model: DROBO DroboPro (scsi)
    Disk /dev/sdg: 17.6TB
    Sector size (logical/physical): 512B/512B
    Partition Table: gpt

    Number Start End Size File system Name Flags
    1 1049kB 16.0TB 16.0TB primary

  • Hi Mark,

    Do you override the automatic fsck check with tune2fs? It would be a huge bummer to do through a check frequently, I forget the defaults but I think
    180 days or a certain number of mounts, iirc.


  • Jason T. Slack-Moehrle wrote:
    We do it manually, when we get to it, and when the users are going to be off long enough….

    Btw, I saw that you said you’d started on 1M – good move. I always start parted with -a optimal. I’ve read that non-optimal alignment can result in serious slowdowns in throughput – half as fast, or even slower.


  • One other option is to boot from a gparted-live CD, which gives you a GUI long enough to partition your volume, then reboot your normal system.


  • Jason T. Slack-Moehrle wrote:

    Disclaimer: I do not speak for my employer, or the US federal government agency (non-DoD) that I work for… but let’s just say serious bioscience data.


  • here’s my parted recipe for making very large volumes… this will fill the disk, reserving 512K up front to be on a reasonable stripe boundary

    |parted /dev/sdb ||”mklabel gpt”|
    |parted -a none /dev/sdb ||”mkpart primary 1024s -1s”|

    I would under NO conditions make a EXT3 volume anywheres NEAR as big as you’re talking about. my preference for large volumes is XFS.

    VG=vg_$(hostname -s)_data
    vgcreate $VG /dev/sdb1
    lvcreate –size 8T –name lv_data $VG
    mkfs.xfs /dev/$VG/lv_data
    mount /dev/$VG/lv_data /data

    if your storage device presents the storage as a block device, then there’s no ‘support’ issues I’m aware of for file systems, its just sectors as far as the storage device is concerned, the file system is strictly up to your OS.

  • I’ve been putting 24-48GB in my servers with large multiterabyte XFS
    volumes. so far, I haven’t had any issues. Some of these systems have
    74TiB file systems (81 TB), primarily used as long term retention archival nearline storage.

  • That’s interesting but it makes me wonder what they are doing wrong. A block device should just deal with data blocks and not know/care about what filesystem is implemented on top of the blocks.