I thought I’d put an answer with my observations because there are a lot of comments. Based off of your output at https://gist.github.com/christian-marie/7bc845d2da7847534104 We can determine the following: The GFP_MASK for the memory allocation tried is allowed to do the following. Can access emergency pools (I think this means access data below the high watermark … Read more
I can see two possible reasons for you to be seeing those file sizes: Sparse files File system corruption Sparse files is a feature on some file systems whereby you can create a file with holes in it. No physical space is allocated for the holes. Reading across the holes will return NUL bytes all … Read more
For XFS, the empty filesystem “Size Used” as shown by df -h seems to depend a lot on which metadata features you enable at mkfs.xfs time. Testing with an empty 12TB file: # truncate -s 12TB xfstest.img Default settings (on my current ArchLinux system): # mkfs.xfs xfstest.img meta-data=xfstest.img isize=512 agcount=11, agsize=268435455 blks = sectsz=512 attr=2, … Read more
The reason for the problem The issue turns out to be in how XFS allocates inodes. Unlike most file systems, allocation happens dynamically as new files are created. However, unless you specify otherwise, inodes are limited to 32-bit values, which means that they must fit within the first terabyte of storage on the file system. … Read more
If you’re attempting to run xfs_repair, getting the error message that suggests mounting the filesystem to replay the log, and after mounting still receiving the same error message, you may need to perform a forced repair (using the -L flag with xfs_repair). This option should be a last resort. For example, I’ll use a case … Read more
At what point does it make sense to depart from the OS-provided kernels and packages when the upstream maintainer has broken an important feature? “At the point where the vendor’s kernel or packages are so horribly broken that they impact your business” is my general answer (coincidentally this is also about the point where I … Read more
As others have pointed out, XFS filesystem cannot be shrunk. So your best bet is to backup /home, remove and recreate its volume in a smaller size and give the rest to your /root volume just as Koen van der Rijt outlined in his post. • backup the contents of /home tar -czvf /root/home.tgz -C … Read more
I generally use one of the following two filesystems: XFS for anything which does not play well with CoW (or for virtual machines whose datastore already is on a CoW filesystem) or when extremely fast direct I/O is required; ZFS for anything else. For your use case I would use ZFS, especially considering that Ubuntu … Read more
I traced this issue back to a discussion about a commit to the XFS source tree from December 2010. The patch was introduced in Kernel 2.6.38 (and obviously, later backported into some popular Linux distribution kernels). The observed fluctuations in disk usage are a result of a new feature; XFS Dynamic Speculative EOF Preallocation. This … Read more
I’ve found XFS more well suited to extremely large filesystems with possibly many large files. I’ve had a functioning 3.6TB XFS filesystem for over 2 years now with no problems. Definately works better than ext3, etc at that size (especially when dealing with many large files and lots of I/O). What you get with ZFS … Read more