Take the 2-minute tour ×
Super User is a question and answer site for computer enthusiasts and power users. It's 100% free, no registration required.

All,

I am finally getting settled into the intricacies of NIX however one thing I am still trying to figure out is why UNIX assigns hard disk space to each directory in its filesystem.

I discovered this while trying to create a new directory in root where I could put ISO's for running Virtual Machines

/isos/

As shown below using df command ; some directories have more space than others

e.g. root has only 700mb assigned to it whilst /export/home has 65gb

    /dev/fd            (fd                ):       0 blocks        0 files
/tmp               (swap              ): 7724392 blocks   576352 files
/var/run           (swap              ): 7724392 blocks   576352 files
/export/home       (/dev/dsk/c0d0s7   ):138187048 blocks  8350700 files
/mnt       

In windows there is no such thing like this I believe; each directory takes space that it needs at that time.

What is the advantage of UNIX managing space this way, it seems a bit inflexible in my opinion or perhaps I am just used to windows too much.

share|improve this question

3 Answers 3

up vote 5 down vote accepted

DF doesn't show folders.
It shows the partitions and how they are "mounted" (linked) within the overall filesystem.

First column is the place in the filesystem where the partition attaches.
2nd gives a reference to the partition itself.
And the other columns show additonal info like size used/free.

You are confusing the fixed size of a filesystem and the underlying partition with the notion of a folder within such a filsesystem.

To further muddy the waters: Some of these partitions are virtual and only exist in memory (/proc, sometimes /tmp) and therefore don't relate to any physical partition on disk at all.

share|improve this answer

I believe you are mistaken about the meaning of those filesystems. On my Kubuntu machine, df yields the following output (by the way, the option -h prints sizes in human units, rather than blocks):

  $ df -h
  Filesystem      Size  Used Avail Use% Mounted on
  /dev/sda1        28G  6,9G   20G  27% /
  none            4,0K     0  4,0K   0% /sys/fs/cgroup
  udev            2,9G  4,0K  2,9G   1% /dev
  tmpfs           585M  1,4M  584M   1% /run
  none            5,0M     0  5,0M   0% /run/lock
  none            2,9G  820K  2,9G   1% /run/shm
  none            100M   20K  100M   1% /run/user
  /dev/sda6       202G   96G   97G  50% /home

Your confusion is born out of the fact that what you call finite space directories are not real filesystems on a disk, but are instead Virtual File systems, i.e. parts of the common *Nix filesystem hierarchy, which are hosted directly inside the pc RAM. RAM filesystems are hosted directly in the pc main memory to allow fastest access to them, so that you will find among them /tmp and /proc. They have a definite size because the RAM is limited in its capacity, and because not all RAM space can be allocated to these filesystems. The use of RAM disks is not limited to the OS, but is open also to a (competent) user: you can learn how to generate one such filesystem in in this ccessible Web page. It should also be clear that, under the unfortunate hypothesis that the space allocated in RAM were to become insufficient, the system would expand the virtual filesystem in the swap area.

share|improve this answer
    
You mean swap yes? –  loosebruce Dec 9 '13 at 11:56
    
@loosebruce You are perfectly right, I have fixed it, thank you. –  MariusMatutiae Dec 9 '13 at 12:03

Actually, it's more like the Windows (CP/M, rather) way of doing things is inflexible.

In DOS and Windows (including the Windows NT line which has spawned e.g. Windows NT 3.x, Windows 2000, Windows XP and Windows 8), until fairly recently there was a one-to-one mapping between disk partitions and file systems. (This was changed by the introduction of volume mount points in Windows 2000, although that remains a rarely used feature perhaps outside of specialized situations.)

Unix-like systems make a clear distinction between the storage device which holds a file system, the file system itself, and the mount point at which that file system is accessible. This is part of the underlying design, and each piece serves an important role.

In Windows, normally the file system on a partition is accessed through that partition's assigned drive letter (for example, C: or E:). In *nix, a file system is normally accessed through a directory path (for example, /export/home possibly relative to the current directory).

The latter is more flexible because in a path, there are no encoded assumptions about the underlying storage. Running out of space on one partition? Just move a large file system that currently exists on that partition to another, update the mount table (in Linux /etc/fstab, might be different on other *nixes) to point the relevant directory to a new physical device, and call it a day. Or split a file system into two by moving a large directory to a file system on a new storage device, and again just update the mount table. Switching to a SAN-based storage architecture rather than per-host storage? Same thing. As far as the users are concerned, this can be done without apparent disruption to anything else aside possibly from the short period of time during which the actual moving of data occurs. Particularly before volume mount points, the same could not be done easily in a Microsoft-centered environment.

When you create a directory /isos you are creating a directory within the root file system, and the storage of what goes into that directory thus must be supported by the root file system. If you later realize that this storage is inadequate, you can take steps to mitigate or rectify that situation without needing to logically move files around, by creating a separate file system and instead mount that on /isos and moving the files into the root directory of that file system, making them visible under /isos when that file system is mounted there.

Keep in mind that Unix was designed as a multi-user system, whereas Windows (and many of the underlying design choices of Windows) traces its lineage back to essentially strictly single-user systems. While this sort of flexibility is likely not needed on a single-user system, it does help greatly in a multi-user setting. (No need for the administrator to pin a notice at the entrance to the terminal room saying "okay everyone, what was previously on D:, except for D:\STUFF, is now on Q:, except for what was in D:\GAMES which is now under R:\WASTE and D:\MATH is now under E:\ALGEBRA, oh and I hope I didn't forget anything"; just shuffle the files around, but keep the logical directories the same.)

share|improve this answer

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.