Installing mSata -> What are the correct Formatting & Setups


I received my Omnia yesterday. I plan to install my 512GB Corsair mSATA SSD before turning it on and doing my initial setup. Any setup comes down to the devil in the details. I’d rather make the best choices first on the initial setup of the SSD.

1/ What the max size mSATA that can be installed?
2/ What is the preferred formatting. EXT4? NTFS? FAT32? what are the trade offs here.
3/ Partitioning. What’s our limit here.
4/ Can we partition and Format from Telnet or SSH? Or is better to set the drive up
from an external Linux / GPARTED and just plug it in?
5/ SSD optimization tools for a given filing system? This is important. Take NTFS and say windows
Windows 7 and above drivers clear up free blocks on and SSD to keep drive speed up over time.
Do we have any SSD optimization tools that can be installed to run in a time based manner
to optimize the SSD for a given filing system? What are they called for reference?


Congratulations and welcome to the club of Omnia owners :smile:

1: Max size has all to do with filesystem, so if you use ext4 for example, if i am not wrong it was up to 16 TB per partition size.

2: I am also busy with this part, but as openWRT is Linux and you are planning to put a mSATA (internal hd) in the Omnia, so just forget about NTFS and FAT32. Rather go use BTRFS or EXT4.

3: Turris OS, is somehow different then openWRT, so for now we are or i better should say i am walking in the darkness about certain things. More research from my side is needed.

4: I put my mSATA drive in and just use “fdisk”. There you can create/delete/format/etc. etc. For formatting for example ext4, just

mkfs.ext4 /dev/sdX

(X being the letter and number of the partition) So if you have sda1 it would be

mkfs.ext4 /dev/sda1

Do remember that you have to create the partition first in fdisk, it is rather simple. If you still need help, you know where to find the forum :).

5: I myself have a Samsung 850 EVO, and the drivers are already within the Linux kernel. “fstrim”, i haven’t configured this yet. For clearing things.

More questions?


ext4 supports up to 1 EB filesystems.

When selecting mSATA drive see also the power ratings for it. I would be careful to go over 3.6W. Drives with larger power ratings might work but if you have issues on the drive or the system then one source for those might be power related.


Some Linux filesystems already support TRIM operation so you don’t need to run fstrim for them. Check the filesystem’s manual for details and if you need to enable TRIM or if it is enabled on default for SSDs. For ext4 there is “discard” option that enables TRIMs.


f2fs is also a really nice choice for ssd’s, very mature and ressource-friendly, imo


On 32-bit architectures, the limit is 16 TB indeed. For anything above that, you need 64-bit CPU, i.e. not Omnia.

Support for the discard option is not in the Omnia kernel (trying to mount the filesystem with it will fail). There’s no fstrim standalone command either. See also this issue.


I cannot find any official material that confirms this. All texts I could find says that ext4 supports 1 EB. There are no references that CPU architecture has any relevance on that.

Although some years ago there were issues reported that many of the ext2/3/4 tools didn’t have support for 64bit ext4 disk layout. At least mkfs has been fixed to support 64bit ext4.

And if I test with Turris Omnia: I can successfully create ext4 filesystem with 64bit layout and mount it:

% mkfs.ext4 -O 64bit abc
mke2fs 1.42.12 (29-Aug-2014)
abc contains a ext4 file system
created on Fri Nov 25 00:54:33 2016
Proceed anyway? (y,n) y
Discarding device blocks: done
Creating filesystem with 64000 1k blocks and 16000 inodes
Filesystem UUID: 3c5d13b5-494f-4c69-a68d-dadf0e32e028
Superblock backups stored on blocks:
8193, 24577, 40961, 57345

Allocating group tables: done
Writing inode tables: done
Creating journal (4096 blocks): done
Writing superblocks and filesystem accounting information: done

% tune2fs -l abc | grep 64bit
Filesystem features: has_journal ext_attr resize_inode dir_index filetype extent 64bit flex_bg sparse_super huge_file uninit_bg dir_nlink extra_isize

% mount ./abc y
% ls -a y
. … lost+found


I don’t know if it actually works but it doesn’t fail in Omnia:

% mount -o discard ./abc y
% ls -a y
. … lost+found

However that test case is not done with SSD drive but with RAM. Maybe somebody else might want to test it with actual SSD drive that supports TRIM.


I’m talking from experience. I have a Synology NAS, with Marvell Armada XP SoC (similar to SoC in Omnia), that has exactly the same problem. Digging a bit more, it does not have 64-bit flag.

Now this is a good news. It was failing three weeks ago and it is not failing anymore. Good catch!


I, like you have a 850 Evo and would like to have two partitions (one for srv and one for storage/file server) and some unused space.

What kind of partition type should I use?
Create 1 Primary partition and 1 extended?


After debating/discussing/pulling out my hair/hitting my head against the wall…

i came to the following conclusion.

2 GB - Majordomo
400 GB - rootfs for lxc

Left the rest unused. Here you have my config setups.

lxc config = veth = br-lan = up = eth0 = 192.168.1.<HIDDEN>/24 =
# Debian workaround = /usr/share/lxc/hooks/tx-off
lxc.tty = 4
lxc.pts = 1024
# Template to generate fixed MAC address = <HIDDEN>
#lxc.rootfs = /srv/lxc/K-Router-LXC/rootfs
lxc.rootfs = /mnt/LXC/K-Router-LXC/rootfs


config global
        option anon_swap '0'
        option anon_mount '0'
        option auto_swap '1'
        option auto_mount '1'
        option delay_root '5'
        option check_fs '0'

config mount
        option target '/mnt/majordomo'
        option enabled '1'
        option uuid '7b511f96-1565-4b0d-b6c5-d7a3e3963e44'
        option fstype 'btrfs'

config mount
        option uuid 'd56b8215-4a67-4e17-a4b9-5dcb05482a17'
        option target '/mnt/LXC'
        option fstype 'btrfs'
        option enabled '1'

fdisk /dev/sda

root@K-Router:/srv/lxc/K-Router-LXC# fdisk /dev/sda

Welcome to fdisk (util-linux 2.25.2).
Changes will remain in memory only, until you decide to write them.
Be careful before using the write command.

Command (m for help): p
Disk /dev/sda: 465.8 GiB, 500107862016 bytes, 976773168 sectors
Units: sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 512 bytes
I/O size (minimum/optimal): 512 bytes / 512 bytes
Disklabel type: dos
Disk identifier: 0x12774218

Device     Boot   Start       End   Sectors  Size Id Type
/dev/sda1          2048   4196351   4194304    2G 83 Linux
/dev/sda2       4196352 843057151 838860800  400G 83 Linux

The LXC mount is not really within LXC, but is just a mounted partition. I can also put other stuff on it if i wanted. If you have anymore questions do ask.

All primary btw.

/srv/ partition du…

root@K-Router:/srv# du -h
4.0K	./lxc/K-Router-LXC
12.0K	./lxc
12.0K	.

df -h

root@K-Router:/mnt# df -h
Filesystem                Size      Used Available Use% Mounted on
/dev/mmcblk0p1            7.3G    763.0M      6.5G  10% /
tmpfs                  1011.2M      2.6M   1008.6M   0% /tmp
tmpfs                   512.0K      4.0K    508.0K   1% /dev
/dev/sda1                 2.0G    115.4M      1.7G   6% /mnt/majordomo
/dev/sda2               400.0G     60.1G    339.0G  15% /mnt/LXC


Wicked nice!
Thank you. :slight_smile:


I’m mounting a Samsung 850 EVO myself this weekend and am planning on going BTRFS for its snapshotting functionality (as lxc-snapshot is still not functional in the Turris OS)?

  • How do you ensure the fstrim to be automatically run (via Cron or do you use the discard mount option with BTRFS)?

Any tips are welcome… as I think TRIM is critical for long-term use!

Moving LXC container to USB

I have used fstrim with a cronjob

20 4 * * * fstrim /mnt/majordomo
30 4 * * * fstrim /mnt/LXC

Every day at 4:20 AM do fstrim on /mnt/majordomo
Every day at 4:30 AM do fstrim on /mnt/LXC

Hope that helps you with it all. If you need any question…or found a better why…do share.


Thanks @Big_boss! That’s exactly what we did (only on a weekly basis though). Two additional questions:

  • You recon it must be done every day? I’ll be running servers in my containers such as: a mailserver / pihole / ftp / nexcloud etc. but only for a very few users.
  • If BTRFS is used does running fstrim on the root “directory” suffice*, or should it be run on each subvolume separately?

Thanks for your (or anyone’s) reply!

P.S. *if I understand this unix stackexchange correctly I think it suffices to only fstrim the main (or any even) volume in the storage pool.


For the record, LInux distributions like openSUSE have cronjobs (or systemd timers) for fstrim once per week.


Well in the past i also used it on weekly basis, however later on got a good argument to have fstrim just daily. It doesn’t do any damage as far as i know and things will keep being fast. While you would have to wait for the week to end for fstrim to take effect. You might don’t write data for lets say 5 weeks, but week 6 just after the “weekly job”, you do the writing and heavily. This will then have to wait until the week is over, while daily well you get the picture.

fstab? you mean fstrim? Well i believe you can only apply it on the root directory only. So in my case i have 2 partitions. LXC and majordomo. That is also what you see there.

I am also right now having Nextcloud on the Ubuntu 16.04 LXC, works wonderful, soon hopefully i will also try running pihole on it.

BTW, i have mariaDB 10.x running, that is oke, however i also have php 7.0 and php7.1 installed, but strangely phpmyadmin doesn’t recognize php7.1 and also Nextcloud uses php7.0 instead of php7.1. I am kind of lazy at the moment but also hopefully soon will dig in to see what is the problem. I though i’ll let you know.


Ow good to know!

I used to think that mounting with the discard option was generally the way to go (but is said to lead to performance loss on BTRFS).

Does Busybox (or Turris’ adaptation thereof) do this as well?


Ok if it indeed doesn’t hurt, why not do it each day (or night at 03:00), got it! Thanks! Will look for second opinions.

Yah root directory I get. But I make extensive use of multiple subvolumes (which are represented as directories but in fact are separate instances of the file-system). I think your answer would still apply (I think fstrimming the root volume is enough, but I am (still) unsure. Can anyone confirm?

Kewl we got that on our list too :slight_smile: first some more basiscs though!

You should :slight_smile: Peace of cake (we had it up and running withing 15 minutes - without exaggerating). But it seems to have some resolving troubles which have to be cleared before I can use it on a dailt basis (but I forgot the details for now).

I know that feeling :wink: and yes please let us know (as stated before we are planning on running Nextcloud too soonish).


Yeah, i think getting the root directory will include the rest.

Just find some good tutorial that guides you using all those steps. There are some very SHALLOW tutorials but some are just a BIT more in depth regarding for example MariaDB and PHP7.

I do recommend to use MariaDB instead of Mysql. Mysql just like openOffice is slowly dying. Al you needs to install with PHP7 some necessary extentions to get Nextcloud working, but you will see it when you are installing it.

I mostly use it to upload some pictures and upload them to other places using laptop but also use “Grauphel” to get my grocery list of what to buy when i am at the shop. In combination with “Tomboy” (on my Linux Ubuntu Desktop), this is ideal and Tomdroid on Android. In Synchronizes perfectly.

About laziness, take your time…the biggest issue we had was getting our Omnia :P. Which we now have. About hardware changes i have also done the necessary tweaking already (replaced 2.4 Ghz with a very strong wifi-card) and the SSD off course. Now it is all about the software side.

Let me know if you need help with anything.