# Seeking explanation for default mount option (solved)

## causality

I recently purchased an 8TB external USB3 disk drive (Seagate model STEL8000100).  Its primary purpose is for backups so I want to fully understand every option applied to it.  This is an Advanced Format device (and also an SMR disk).  Its physical sector size is 4k, though it reports a logical sector size of 512b to the BIOS (I think Linux is smart enough to just use the 4k figure).

I nuked the NTFS partition it came with and used the utility gdisk to create a GPT partition.  This partition is aligned correctly at the first sector (that is, the program parted's align-check function says "yes" for "min", though "no" for "opt" - I assume because the partition takes up the whole device, which does not end on a sector number evenly divisible by both 4k and 512b - that's OK for me).  Please advise if my assumption there is wrong.

I then formatted that partition using mkfs.ext4, at which time I specified a 4k block size on the command line.  All other options are defaults as specified in the (unmodified) Gentoo-supplied /etc/mke2fs.conf file.  That files does not set a "stripe=" mount option anywhere, nor did I manually add one.

Anytime I mount it specifying no options (i.e. mount /dev/sde1 /mountpoint), the mount option "stripe=8191" is automatically appended.  Apparently this was automatically added as a default mount option as shown by running "tune2fs -l /dev/sde1".

I have always associated "stripe" and its related options with RAID arrays.  Every Startpage search I make results in RAID information, which makes sense.  However, this is not a RAID array.  It is a single hard disk, containing a single partition, hosting a single filesystem.  I'm not even using LVM or anything.  It's just a plain disk.

I can't find any good reason for this.  Why was that option appended and where did it come from?  Is it important?  Will there be some problem if I remove it from the default mount options?  Is it helping anything?  Considering that these are all open source tools with generally excellent documentation, it's astonishingly hard to answer these questions.

As this is a backup device I would feel better completely understanding it.  Mysterious options I did not set, cannot trace, and do not seem to fit my use case, well that concerns me a bit.    :Surprised:    Please advise.Last edited by causality on Mon Apr 03, 2017 7:07 pm; edited 1 time in total

----------

## Ant P.

See e2fsprogs/misc/mke2fs.c:1423 - it looks up the right write size from /sys/block/sd?/queue/{minimum,optimal}_io_size and sets the stripe width in the superblock from that. The kernel just picks up the option from there. It's labelled "raid_stripe_width" in the code but that's mostly for historical reasons at this point.

----------

## causality

I was actually just looking through the source when I received the e-mail notification of your reply.

What threw me off is that none of my other drives have this default mount option set in the superblock.  If they had, I would have regarded it as normal behavior.  I suppose this is because my other filesystems were all created years ago and in the past, mke2fs didn't behave this way unless you explicitly used the -E stripe=X option at filesystem creation time.  I'm not sure about that (never considered RAID options before at all) but it would make sense.

So far as I know, I can use tune2fs to remove this option with no harm, since I have no RAID array.

Regarding alignment, this is where the drive stands right now according to parted:

```
GNU Parted 3.2

Using /dev/sde

Welcome to GNU Parted! Type 'help' to view a list of commands.

(parted) print                                                            

Model: Seagate Backup+ Hub BK (scsi)

Disk /dev/sde: 8002GB

Sector size (logical/physical): 512B/4096B

Partition Table: gpt

Disk Flags: 

Number  Start   End     Size    File system  Name  Flags

 1      1049kB  8002GB  8002GB  ext4

(parted) unit s

(parted) print                                                            

Model: Seagate Backup+ Hub BK (scsi)

Disk /dev/sde: 15628053167s

Sector size (logical/physical): 512B/4096B

Partition Table: gpt

Disk Flags: 

Number  Start  End           Size          File system  Name  Flags

 1      2048s  15628053133s  15628051086s  ext4

(parted) align-check min 1                                                

1 aligned

(parted) align-check opt 1                                                

1 not aligned

(parted)  
```

This is the partition information from gdisk (which was used to create the partition):

```
GPT fdisk (gdisk) version 1.0.1

Partition table scan:

  MBR: protective

  BSD: not present

  APM: not present

  GPT: present

Found valid GPT with protective MBR; using GPT.

Command (? for help): p

Disk /dev/sde: 15628053167 sectors, 7.3 TiB

Logical sector size: 512 bytes

Disk identifier (GUID): F8ACD6BA-FBDC-44AC-8E8B-843A5BB90E2C

Partition table holds up to 128 entries

First usable sector is 34, last usable sector is 15628053133

Partitions will be aligned on 2048-sector boundaries

Total free space is 2014 sectors (1007.0 KiB)

Number  Start (sector)    End (sector)  Size       Code  Name

   1            2048     15628053133   7.3 TiB     8300  

```

Gdisk seems to be more aware of the "Advanced Format" layout.  It starts on an aligned sector (2048) and if it "will be aligned on 2048-sector boundaries" then I don't know what else I could have done.  In fact the performance of reading and writing large amounts of data (much more than my RAM could cache) is consistent with both the specifications of the device, and the filesystem-agnostic output of "hdparm -tT /dev/sde".

Do you think maybe parted's "align-check opt 1" says "not aligned" because the different physical sector size (4k) and logical sector size (512b) is confusing it?  This is the only drive I own which is Advanced Format.  

Thank you for helping me figure this out.  I'm unaccustomed to not finding program behavior documented someplace other than the source code, as documentation is typically excellent for major open source projects.  Or at least Web searches yield good results.  If it were something other than a backup device I'd be much less picky about annoying little mysteries like this.    :Very Happy: 

----------

## Sadako

One question, why partition the disk at all if you're only going to have one partition take up the entire disk anyway?

Only reason I can think of is if you're booting from that device, which doesn't seem to be the case here.

----------

## causality

Sadako:  partly out of habit and partly because I don't know if "mkfs.ext4 -b 4096 /dev/sde" would result in a favorable sector alignment.  Do you know for certain if it would?

The downside of my choice to partition:  according to gdisk sector number 34 is the "first usable sector".  4k sectors, first usable sector is 34, filesystem starts on sector 2048.   That's 4096 * (2048 - 34) = 8249344 bytes unused.  On an 8TB drive, this is such a tiny fraction of one percent that I consider it negligible.  For that tiny (practically zero) price, I gain the certainty of avoiding the performance hit of all the excess I/O caused by misalignment.

This drive isn't hosting a database or anything like that where the absolute max performance is critical (I'd shell out for an SSD in that case).  In fact my favored trade-off in this instance was:  a larger drive with a low price-per-GB rather than spending the same money for a smaller but faster disk.  Indeed, inside the USB3 enclosure is a Seagate Archival drive.  Still, I intend to store large amounts of data so I'll take whatever performance gain I can get especially when said gain is essentially free.

I think I'm satisfied with my setup now, but still I wonder:  do you know of any advantages to just using the entire /dev/sde block device without partitions?  Any disadvantages?  Am I overlooking something potentially significant?  The great thing about a forum like this, is that one can learn much just by listening.

----------

## Sadako

Yes, "mkfs.ext4 -b 4096 /dev/sde" would result in optimal alignment, think of it this way, when partioned you need to concern yourself with both the partitioning scheme AND the filesystem wrt alignment, using the whole disk you eliminate the former.

That said, there's nothing "wrong" with a single partition taking up the whole disk, only issue is wasting of a few bytes which is absolutely inconsequential giving the size of the disk (although, iirc gpt creates an identical partition table at the end as well as the start of the disk).

----------

## causality

There is one more thing I don't understand:  how to get rid of that stripe= mount option.

I unmounted the device.  I ran tune2fs -E mount_opts="" /dev/sde1.  I also ran "tune2fs -o ^acl,^user_xattr".  Currently this is the output of tune2fs /dev/sde1:

```
tune2fs 1.43.4 (31-Jan-2017)

Filesystem volume name:   <none>

Last mounted on:          /home/light/media

Filesystem UUID:          16cdfe07-3257-49bb-90cf-ae00aad3448f

Filesystem magic number:  0xEF53

Filesystem revision #:    1 (dynamic)

Filesystem features:      has_journal ext_attr resize_inode dir_index filetype needs_recovery extent 64bit flex_bg sparse_super large_file huge_file uninit_bg dir_nlink extra_isize

Filesystem flags:         signed_directory_hash 

Default mount options:    (none)

Filesystem state:         clean

Errors behavior:          Continue

Filesystem OS type:       Linux

Inode count:              244191232

Block count:              1953506385

Reserved block count:     97675319

Free blocks:              1028282373

Free inodes:              244145660

First block:              0

Block size:               4096

Fragment size:            4096

Group descriptor size:    64

Reserved GDT blocks:      1024

Blocks per group:         32768

Fragments per group:      32768

Inodes per group:         4096

Inode blocks per group:   256

RAID stripe width:        8191

Flex block group size:    16

Filesystem created:       Tue Mar 28 23:20:24 2017

Last mount time:          Mon Apr  3 16:29:44 2017

Last write time:          Mon Apr  3 16:29:44 2017

Mount count:              5

Maximum mount count:      -1

Last checked:             Tue Mar 28 23:20:24 2017

Check interval:           0 (<none>)

Lifetime writes:          3589 GB

Reserved blocks uid:      0 (user root)

Reserved blocks gid:      0 (group root)

First inode:              11

Inode size:               256

Required extra isize:     32

Desired extra isize:      32

Journal inode:            8

Default directory hash:   half_md4

Directory Hash Seed:      470be453-993f-4722-bffa-baa37fd2a689

Journal backup:           inode blocks

```

Yet if I do a test mount, like "mount /dev/sde1 /mnt/tmp", there it is again:

```
/dev/sde1 on /mnt/tmp type ext4 (rw,relatime,stripe=8191,data=ordered)
```

Even directly overriding it like "mount /dev/sde1 /mnt/tmp -o stripe=0" makes no difference.  I tried that and there it is, stripe=8191.  I've been using Linux a long time - normally it does whatever you tell it to do, even if you're shooting yourself in the foot.   :Cool: 

Stripe= is not specified in my /etc/fstab.  As far as I know it's not in the superblock either, or if it is, it's not visible to tune2fs.  For that matter, relatime isn't present either.  These defaults have to be coming from someplace.  At least I understand that data=ordered is the ext4 default journal setting.

Performing "grep -R relatime /etc/*" doesn't turn up anything useful.  Neither does "grep -R stripe /etc/*"  Where are these specified?  Where is that stripe option stored?  I've never had such a hard time tracking down a simple option like this.

This one thing is more like using Windows   :Twisted Evil:    Ok, so it's not that bad ...

----------

## Sadako

wrt relatime, from mount man page; *Quote:*   

> Since  Linux 2.6.30, the kernel defaults to the behavior provided by this option (unless noatime was specified), and the strictatime option is required to obtain
> 
> traditional semantics.  In addition, since Linux 2.6.30, the file's last access time is always updated if it is more than 1 day old.

 meaning you'll see relatime for all mounts unless you explicitly set noatime or similar.

As for the stripe width, you could try 'tune2fs -E stripe_width= /dev/sde1', I have no idea if it`ll have any effect though.

----------

## causality

Since I never specified that, nor any other RAID related parameter, I assume that even repartitioning and reformatting from scratch would yield the same result.

I was finally able to get rid of it via "tune2fs -E "" /dev/sde1".  Prior to that I tried your command with the stripe= syntax.  One of those got it.  I may make a feature request to upstream e2fsprogs, asking that the tune2fs program do a better job of showing currently set extended mount options.  That would have saved me some time trying to track this down.

I really appreciate all the help with this, especially considering it's a relatively minor issue.  Sometimes I want to solve a puzzle just because I feel like I should be able to understand it, and because it's there   :Very Happy: .  It's why a lot of mountaineers climb mountains.  They learn much along the way.

Nobody beats the Gentoo user community in terms of expertise and willingness to share knowledge.  It's a major reason I've stuck with Gentoo all these years.  Well, that and I truly love what Gentoo is all about (choice) and the way they do things.  In fact this forum is one of the first places I look for any Linux question, even if it's another distribution, just because the information is so good.

----------

## shrike

 *Sadako wrote:*   

> Yes, "mkfs.ext4 -b 4096 /dev/sde" would result in optimal alignment, think of it this way, when partioned you need to concern yourself with both the partitioning scheme AND the filesystem wrt alignment, using the whole disk you eliminate the former.
> 
> That said, there's nothing "wrong" with a single partition taking up the whole disk, only issue is wasting of a few bytes which is absolutely inconsequential giving the size of the disk (although, iirc gpt creates an identical partition table at the end as well as the start of the disk).

 

Thanks! I was not aware of this outside of ZFS' preference for whole disk sans partition. I assumed some superior ZFS disk translations handling and thought nothing more of it. 

shrike

----------

