1

I've initialised one large primary partition with the -T small flag to mke2fs, small on the system is configured as follows:

    small = {
            blocksize = 1024
            inode_size = 128
            inode_ratio = 4096
    }

This is a 800 GB SSD (cloud drive) which will be a home for the 10+ million small files, ranging from ~10KB to ~100KB.

I tried to go thoroughly the man pages of mount and figure out the best combo of flags and here's my list:

  • rw - read and write
  • nosuid - no need for user or group ID on execution
  • nodev - block dev files should never appear in here
  • noexec - files with exec bit set are also not welcome
  • auto - allow mount -a
  • nouser - only root can (re)mount
  • async - async writing
  • relatime - update access time only when files are modified.
  • data=ordered - presumably should improve read performance
  • errors=remount-ro - stop writing when errors
  • discard - recommended for SSD
  • auto_da_alloc - fight filesystem corruption in case of power failure (perhaps not needed, as this is a cloud drive?)
  • inode_readahead_blks=16 - file system will be a home for the great bunch of small files, hence big readahead should be nothing more but a performance penalty. I didn't know the optimal value for files of average size 50KB, so just put here twice as less value as the default.
  • debug

I really need a second opinion from someone more experienced in these matters. I'm particularly unsure about the discard, relatime, data=ordered, auto_da_alloc, inode_readahead_blks and other flags, which I have missed or misunderstood. How dangerous is data=writeback? How much data I may loose with such flag, is it just the last 5 sec (default value of commit)? Other insight regarding this exercise?

NarūnasK
  • 368
  • 4
  • 17
  • 1
    Why have you chosen ext4 for your filesystem? – Michael Hampton May 14 '16 at 22:03
  • My playground here is the production server, hence I need `fs` that was well tested by many and proven being stable and efficient. – NarūnasK May 14 '16 at 22:13
  • What kind of storage controller are you on? Is it battery backed? This will have a pretty significant impact on some flags you can/cannot safely use that may have some pretty big performance impacts. – dodexahedron Jun 13 '16 at 01:47

2 Answers2

1

You should probably just use the XFS filesystem for this.

ext4 is not well-suited to this workload because you're on an SSD and have a stupid-high file count. There's a reason Red Hat now defaults to XFS.

Community
  • 1
ewwhite
  • 197,159
  • 92
  • 443
  • 809
  • Thanks, but based on [this](http://unix.stackexchange.com/a/28792/111103), `XFS` perhaps is the last thing I should use for the great number of small files, unless you can argue these results. – NarūnasK May 15 '16 at 08:08
  • 1
    ***Do what you want...*** or just test with your own data set. – ewwhite May 15 '16 at 08:09
  • Your statement that I should just use `XFS` is not very convincing, especially when there's evidence showing otherwise... – NarūnasK May 15 '16 at 08:16
  • 1
    Okay, then you've arrived at your own conclusion. – ewwhite May 15 '16 at 08:18
  • @NarūnasK *Your statement that I should just use XFS is not very convincing* And that benchmark you linked to isn't very convincing, either. Benchmarks that don't specify the hardware being used are useless. – Andrew Henle May 16 '16 at 09:59
0

Why not consider using ZFS on linux? ZFS is definetly superior to ext4 and it's considered production ready on linux. See http://www.phoronix.com/scan.php?page=news_item&px=MTc4NTM

It's not difficult to install; see http://zfsonlinux.org/ for installation info.

Pierre.Vriens
  • 1,159
  • 34
  • 15
  • 19
Peter
  • 152
  • 5
  • Thank you for your input. `zfs` was noted and expelled from the list due to the fact, that it is not supported in Debian (because of the licensing) and its greedy constraints of the memory. I agree, that `zfs` is superior system and RAM these days is relatively cheap, however decisions already made. – NarūnasK May 14 '16 at 23:14
  • 1
    @NarūnasK *`zfs` was noted and expelled from the list due to the fact, that it is not supported in Debian (because of the licensing)* So you've already decided on your solution and you're now force-fitting your problems into that solution. That's backwards. – Andrew Henle May 16 '16 at 10:04
  • No, these answers just don't answer his question. He didn't ask for another file system. He asked about the flags for mounting the file system he's already chosen. – dodexahedron Jun 13 '16 at 01:44