Google has parsed this Duke University IT knowledgebase article into an infocard alleging to anyone searching "linux quota block size" that

A block quota is the limit on the actual amount of disk space that can be used by an account. This space is measured in 1 KB blocks (1 KB = 1024 bytes or characters).

A quick search on this site yielded this answer referring to other definitions of "block size", including EXT4's:

A typical block size is 4KiB.

I poked around in these source files a bit, but their code is so sparsely commented that I was unable to grok it.

I still vaguely assume that quota(1) reports "block size" in the associated filesystem's specific block (size rather than a universal constant like 1KiB), but how could I verify this? Where is the point of contact between the quota tooling codebase and the filesystem driver codebase?

1 Answer 1


There is no universal constant of block size; "The UNIX Programming Environment" (1984) on page 50 states for du(1)

The filenames are obvious; the numbers are the number of disc blocks -- typically 512 or 1024 bytes each -- of storage for each file.

4096 is also popular these days.

That being said, for the http://sourceforge.net/projects/linuxquota/ tools (which may differ from other implementations) the edquota(8) documentation indicates

Block usage and limits are reported and interpereted as multiples of kibibyte (1024 bytes) blocks by default. Symbols K, M, G, and T can be appended to numeric value to express kibibytes, mebibytes, gibibytes, and tebibytes.

And in xfs_quota(8) one might find

There are four numbers for each limit: current usage, soft limit (quota), hard limit, and time limit. The soft limit is the number of 1K-blocks (or files) that the user is expected to remain below. ... report [ -gpu ] [ -bir ] [ -ahntlLNU ] [ -f file ] Report filesystem quota information. This reports all quota usage for a filesystem, for the specified quota type (u/g/p and/or blocks/inodes/realtime). It reports blocks in 1KB units by default. The -h option reports in a "human-readable" format similar to the df(1) command.

"interpereted as multiples of" could easily support 4096; a user consuming one 4096 block on a -b 4096 filesystem should be reported as consuming four 1024 blocks by the quota system. This might be slightly inaccurate for a 1024 byte lens of a 512 block filesystem. However according to mkfs.ext2 EXT2 only supports 1024 blocks or larger:

OPTIONS -b block-size Specify the size of blocks in bytes. Valid block-size values are 1024, 2048 and 4096 bytes per block.

So converting those to 1024 bytes for display would never be wrong, provided the program can do the math aright.

XFS allows you to create -b 512 filesystems, so an easy test for verification there would be to create a -b 512 filesystem and a -b 1024 filesystem, enable quotas on them, and write 512 bytes for a user on both. If the 1024-for-quota-display holds, both of them should show 1 block consumed. Then write 512 more bytes, and they still both should show 1 block used.

head -c 512 /dev/zero > a_test_file

Otherwise you could test with a -b 4096 filesystem and see if the quotas are reported in units of 1024 as the documentation for the quota or filesystems listed above indicates it should be. For other quota software, check the documentation, and verify by performing file write tests. File write tests are a pretty good way to know if the hard limits are working, that the warnings and reporting are all good, that suitable documentation exists, etc.

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .