I came to the conclusion that aufs is limited to 127 layers based on tests.


mkdir write joined {1..400}
for((i=1;i<=400;i++));do echo >$i/$i.txt;done #for checks

using a single mount, the limit is 84 layers (numbereds + the write one).

The folder name doesn't change the 84 limit (so each could be bigger ex. "layer-72", therefore not a string size limitation).

sudo mount -v -t aufs \
  -o "sync,br=write:1:2:3:4:5:6:7:8:9:10:11:12:13:14:15:16:17:18:19:20:21:22:23:24:25:26:27:28:29:30:31:32:33:34:35:36:37:38:39:40:41:42:43:44:45:46:47:48:49:50:51:52:53:54:55:56:57:58:59:60:61:62:63:64:65:66:67:68:69:70:71:72:73:74:75:76:77:78:79:80:81:82:83:84" \
  "none" "joined";echo $?

The above will fail, unless you remove ":84" from the end.

Using remount, it can go up to 127 layers (numbereds + the write one)

sudo mount -v -t aufs -o "sync,br=write" "none" "joined";echo $?
  echo "try $i";
  if ! "sudo" "mount" -v "-o" "remount,append:$i" "joined";then
    break; # it stops with error "No space left on device", but is not related to free bytes on storage!
  ls -l joined/$i.txt;


I am trying to use mount.aufs just to see readable error messages, as mount -v is not helping.

Is there documentation specifying how to translate mount parameters to mount.aufs?

I am still trying to find mount.aufs source code too; that could help my understanding of what parameters it accepts.

Alternative acceptable answer

Is aufs patchable (as apparently 127 is a hard-coded limit)? Is it worth the effort/mess, or more than 127 may cause performance issues as suggested on comments?

Could an alternative folders merger provide more than 127 layers? If so, which one? Here a list I found: overlayfs unionfs mhddfs mergerfs docker. What commands I should use based on the test case I provided above? aufs is quite clear and simple to use and understand, and that was the main reason I chose it.

  • 1
    Why do you need 83 layers? – Stephen Kitt Nov 12 '17 at 13:08
  • @StephenKitt later I need about 300 layers, but currently I am aiming at +-120 layers. It is a good way to install modifications without dropping the files directly on the same main/target folder, so each modification has it's own folder making it a lot easy to uninstall it, and the target is the merged thru aufs – Aquarius Power Nov 12 '17 at 13:33
  • Likely using some sort of source code control system will be far easier than managing aufs like this. Also each layer of aufs adds additional overhead. I guess if your file access is minimal or you have many free/fast CPUs with no work to do... you'll be okay. My guess is eventually this approach will create many problems over time. – David Favor Nov 12 '17 at 13:53
  • @DavidFavor I only actually need the final merged one for read-only, but if anything minimal is written (usually logs and config files), it goes to the write layer. It is mainly to keep it organized and easy to maintain. – Aquarius Power Nov 12 '17 at 14:15
  • 1
    @AquariusPower AUFS has a hard limit of 127 layers. You won't be able to exceed that without changing the underlying filesystem. I don't know if OverlayFS has a higher limit, but the latter has the slight advantage of being included in mainline Linux. Or, Docker likes devicemapper – Fox Nov 12 '17 at 19:50

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Browse other questions tagged or ask your own question.