![]() For ext2, ext3, and ext4 filesystems, you can inspect this data, stored in the filesystem superblock, by using the tune2fs command. Only root, or root-owned processes, can write files to consume this disk space. The root user's file creation works because the ext4 filesystem holds onto some reserved space that non-privileged users can not access. The touch command creates an empty file, which means it consumes an inode to store the file metadata but does not consume any associated data blocks. That is confirmed by using another option with the df command: mnt]# df -iįilesystem Inodes IUsed IFree IUse% Mounted on ![]() However, the filesystem has plenty of inodes (file pointers) available. The reason touch works is that the filesystem is out of data blocks for storing file contents. However, if they use touch to create a file, they see this: mnt]$ touch mnt]$ lsĪdditionally, if root creates a file by using dd, it works without a problem, as shown below: mnt]# dd if=/dev/zero of=root-file count=100ĥ1200 bytes (51 kB, 50 KiB) copied, 0.000748385 s, 68.4 mnt]# lsĬlearly, creating files is successful through dd or touch if you are root! What is going on? Yet, when a user runs a command to consume more disk space, such as the dd command, they get the following message: mnt]$ dd if=/dev/zero of=bigfile2ĭd: writing to 'bigfile2': No space left on device The situation: A user reports that the filesystem is full, but when I look at the disk free ( df) output, I see the following: ~]# df -hįilesystem Size Used Avail Use% Mounted onįrom the above output, you notice that the Size is reported at 991 MB, but the Used is 924 MB, clearly not full. ![]() Toward the end of this section, there is a specific discussion about how these topics affect XFS. However, Red Hat Enterprise Linux now deploys XFS as the default filesystem. The content below is based on a traditional extended filesystem that is deployed on a lot of different Linuxes, specifically ext4. Here is an article on binary prefix if you'd like even more details. ![]() For example, see my fdisk utility output from a Red Hat Enterprise Linux 8.2 system below: Disk /dev/sda: 20 GiB, 21474836480 bytes, 41943040 sectors Modern versions of tools have already started using this method. This means you can still buy your 1 TB drive, but disk utilities should report it as 977 GiB to reflect that the disk utility is using a factor of 1024 for measurement, not the metric, 1000, measurement factor. Enter the GiB and TiB (the other smaller and larger units follow the same nomenclature). So what is to be done? International standards bodies, like the International Electrotechnical Commission (IEC) and International Organization for Standardization (ISO), have created a unit of measurement to account for the difference in usage between true metric and the rough approximation that we have been using in computing. However, as we get larger and larger files, memory, drives, packets, etc., this difference is more and more noticeable. Wow, that is incredibly annoying! Not to mention not really standards-based, which is something the open-source community is all about, right? Essentially, in the computer industry, we have been abusing the fact that 1024 is darn close to 1000. This difference in the units of measure is the difference between 1 TB or 977 GB. However, in the computer world, we don't operate at the power of 10, we operate by powers of two, so for us, 1024 GB = 1 TB. Disk manufacturers use true metric measurements, so 1000 GB = 1 TB. Nowhere, and depending on your opinion, it either is still or was never there! This difference comes from disk manufacturers and operating system programmers using different units of measurement. Cheat sheet: Old Linux commands and their modern replacements.Linux system administration skills assessment.A guide to installing applications on Linux.Download RHEL 9 at no charge through the Red Hat Developer program.
0 Comments
Leave a Reply. |
AuthorWrite something about yourself. No need to be fancy, just an overview. ArchivesCategories |