On Fri, 14 Feb 2020 09:00:28 -0500
Anton Aylward
On 13/02/2020 15:29, Istvan Gabor wrote:
I would like to find out how much space is available for a regular user on an ext4 file system.
ROTFLMAO!
For ALL the file systems I've ever dealt with the concepts of "usable space" and "Free space" are distinct.
Nn Ancient of Days, that is before the Internet, before Linux, before the UNIX Systems Group got it's sticky fingers on the the source, there was the traditional, known as V7, file system. This offered stability and integrity over the V6 file system by ordering writes to metadata.
The V6/V7 set a tradition in file system that has held for nearly half a century now: that there is i-node space and there is data space and one may become exhausted before the other.
Now there are file systems that break with that tradition, most visibly ReiserFS and BtrFS. Each them allocates BOTH i-nodes and data dynamically from a pool, all of that being managed by B-tree lists. Because BOTH come from the same pool one can never be exhausted before the other.
I'm an advocate of ReiserFS and consider pre-allocation for be a Major Sin of File System design.
Not Ext4 adherents might claim B-tree-ness, but they still have this inode space division and the amount of inodes determined at MKFS-time. In my opinion the ratio of the number of inodes to the file system space is huge, but YMMV. The preallocation means one can run out before the other, usually data space running out before inodes. Yes, you can tune the bytes-per-inode, number of inodes and the inode size. great if you have done metrication and probably a lot of step-and-repeat and load testing and logged your results and understand they dynamics of the application or application set that will be using the file system and can systematically justify your settings.
But I don't think this is what Istvan is asking for.
The TRUE B-tree file systems like ReiserFS and BtrFs WILL tell you how much free space is available. What they won't tell you is how that is contained, because it isn't. Running stat's on those file systems won't tell you what percentage of the inodes are used and hence how many files you can create now, because the concept is meaningless.
Let me insert a sort-of-sidebar here. We still have a legacy from the V6/V7 days of reporting file systems sizes in 512 byte blocks. But we gave up on using 512 blocks about the time the DEC VAX was introduced. The Berkeley Fast File System moved to 4K blocks for a variety of reasons and we've been there ever since. Initially (and still) the kernel did the re-blocking of the locial-4K to the disk's 512, but recently disk manufacturers have caught up with the idea. I won't go into the justifications for of the analysis behind this, just say that bigger script programs and larger binaries were contributing factors.
See PAGESIZE(1)
One thing did emerge from the 4K blocks. We still had many files that were small. Take a look at the files under /etc and see how many are under 512 bytes. Come to that, see how many are under 64 or even 32 bytes.
find /etc -type f -size -2b -print0 | xargs -0 ls -l
Some file systems try putting those very small files into the inode space. Consider: the inode space has room for a pointers to the direct and possibly indirect blocks. How big are those fields? https://ext4.wiki.kernel.org/index.php/Ext4_Disk_Layout#Inline_Data
So" in theory, at least. it is possible, if all the data space of an ext4FS is exhausted before the inode space, to create a small file whose data resides in the inode.
Now do you see why the concept of "usable" and "free" space is pretty arbitrary? The only thing that matter becomes "is there enough for the needs?" As illustrated above, if the needs is just a few bytes like the dozen or so of a hostname, ...
I wonder if anybody else got to the end and wondered, like me, why XFS didn't get a mention? JFS and ZFS I can understand, but XFS is a mainstream system. Oh, and it's well-known that btrfs doesn't tell you the truth unless you ask it in a very particular way. -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org