Gentoo Forums
Gentoo Forums
Gentoo Forums
Quick Search: in
Seeking explanation for default mount option (solved)
View unanswered posts
View posts from last 24 hours

 
Reply to topic    Gentoo Forums Forum Index Kernel & Hardware
View previous topic :: View next topic  
Author Message
causality
Apprentice
Apprentice


Joined: 03 Jun 2006
Posts: 228

PostPosted: Mon Apr 03, 2017 4:57 pm    Post subject: Seeking explanation for default mount option (solved) Reply with quote

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. :o Please advise.


Last edited by causality on Mon Apr 03, 2017 7:07 pm; edited 1 time in total
Back to top
View user's profile Send private message
Ant P.
Watchman
Watchman


Joined: 18 Apr 2009
Posts: 5761

PostPosted: Mon Apr 03, 2017 6:36 pm    Post subject: Reply with quote

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.
Back to top
View user's profile Send private message
causality
Apprentice
Apprentice


Joined: 03 Jun 2006
Posts: 228

PostPosted: Mon Apr 03, 2017 7:06 pm    Post subject: Reply with quote

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:

Code:
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):

Code:
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. :D
Back to top
View user's profile Send private message
Sadako
Advocate
Advocate


Joined: 05 Aug 2004
Posts: 3789
Location: sleeping in the bathtub

PostPosted: Mon Apr 03, 2017 7:38 pm    Post subject: Reply with quote

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.
_________________
"You have to invite me in"
Back to top
View user's profile Send private message
causality
Apprentice
Apprentice


Joined: 03 Jun 2006
Posts: 228

PostPosted: Mon Apr 03, 2017 8:04 pm    Post subject: Reply with quote

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.
Back to top
View user's profile Send private message
Sadako
Advocate
Advocate


Joined: 05 Aug 2004
Posts: 3789
Location: sleeping in the bathtub

PostPosted: Mon Apr 03, 2017 8:28 pm    Post subject: Reply with quote

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).
_________________
"You have to invite me in"
Back to top
View user's profile Send private message
causality
Apprentice
Apprentice


Joined: 03 Jun 2006
Posts: 228

PostPosted: Mon Apr 03, 2017 8:40 pm    Post subject: Reply with quote

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:

Code:
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:

Code:
/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. 8)

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: Ok, so it's not that bad ...
Back to top
View user's profile Send private message
Sadako
Advocate
Advocate


Joined: 05 Aug 2004
Posts: 3789
Location: sleeping in the bathtub

PostPosted: Mon Apr 03, 2017 9:09 pm    Post subject: Reply with quote

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.
_________________
"You have to invite me in"
Back to top
View user's profile Send private message
causality
Apprentice
Apprentice


Joined: 03 Jun 2006
Posts: 228

PostPosted: Mon Apr 03, 2017 10:13 pm    Post subject: Reply with quote

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 :D. 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.
Back to top
View user's profile Send private message
shrike
Tux's lil' helper
Tux's lil' helper


Joined: 20 Feb 2004
Posts: 136
Location: Closer to home

PostPosted: Tue Apr 04, 2017 1:14 pm    Post subject: Reply with quote

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
Back to top
View user's profile Send private message
Display posts from previous:   
Reply to topic    Gentoo Forums Forum Index Kernel & Hardware All times are GMT
Page 1 of 1

 
Jump to:  
You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot vote in polls in this forum