UNIX против файловой системы Windows; почему UNIX назначает конечное пространство для каждого каталога?

Question

Все,

Я, наконец, разбираюсь в тонкостях NIX, однако одну вещь, которую я все еще пытаюсь выяснить, - почему UNIX назначает место на жестком диске каждому каталогу в своей файловой системе.

Я обнаружил это при попытке создать новый каталог в корневом каталоге, где я мог бы поместить ISO для запуска виртуальных машин

/ ISOS /

Как показано ниже с использованием команды df; некоторые каталоги имеют больше места, чем другие

например, root имеет только 700 МБ, а /export /home - 65 ГБ

    /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       

Я думаю, что в окнах такого нет; каждый каталог занимает место, в котором он нуждается в то время.

Каково преимущество UNIX в управлении пространством таким образом, на мой взгляд, оно немного негибко, или, может быть, я слишком привык к окнам.

Answer 1

DF не показывает папки.
Он показывает разделы и то, как они "монтируются" (связаны) в общей файловой системе.

Первый столбец - это место в файловой системе, к которому присоединяется раздел.
2-й дает ссылку на сам раздел.
А другие столбцы показывают дополнительную информацию, такую как используемый размер / свободный.

Вы путаете фиксированный размер файловой системы и нижележащего раздела с понятием папки в такой файловой системе.

Чтобы еще больше запутаться: некоторые из этих разделов являются виртуальными и существуют только в памяти (/proc, иногда /tmp) и, следовательно, не имеют отношения к физическим разделам на диске вообще.

Answer 2

Я полагаю, что вы ошибаетесь в значении этих файловых систем. На моей машине Kubuntu, df выдает следующий вывод (кстати, опция -h печатает размеры в human единицах, а не в блоках):

  $ 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

Ваша путаница возникает из-за того, что то, что вы называете finite space directories - это не реальные файловые системы на диске, а виртуальные файловые системы, i.e. части общей иерархии файловых систем * Nix, которые размещаются непосредственно в оперативной памяти компьютера. Файловые системы ОЗУ размещаются непосредственно в основной памяти ПК, чтобы обеспечить быстрый доступ к ним, так что вы найдете среди них /tmp и /proc . Они имеют определенный размер, поскольку объем ОЗУ ограничен, а также не все пространство ОЗУ может быть выделено для этих файловых систем. Использование RAM-дисков не ограничено ОС, но открыто и для (компетентного) пользователя: вы можете узнать, как создать одну такую файловую систему на этой доступной веб-странице . Также должно быть ясно, что в соответствии с неудачной гипотезой о том, что места, выделенного в ОЗУ, станет недостаточно, система расширит виртуальную файловую систему в области подкачки.

Answer 3

На самом деле, это больше похоже на Windows (CP/M, скорее) способ делать вещи негибки.

В DOS и Windows (включая линию Windows NT, которая породила, например, Windows NT 3.x, Windows 2000, Windows XP и Windows 8), до недавнего времени существовало однозначное сопоставление между разделами диска и файловыми системами. (Это было изменено введением точек монтирования тома в Windows 2000, хотя это остается редко используемой функцией, возможно, за пределами специализированных ситуаций.)

В Unix-подобных системах проводится четкое различие между устройством хранения, в котором находится файловая система, самой файловой системой и точкой монтирования, в которой эта файловая система доступна. Это часть основного дизайна, и каждая часть играет важную роль.

В Windows обычно доступ к файловой системе раздела осуществляется через назначенную букву диска этого раздела (например, C: или E: . В * nix к файловой системе обычно обращаются через путь к каталогу (например, /export/home возможно, относительно текущего каталога).

Последнее является более гибким, поскольку в пути нет закодированных предположений о базовом хранилище. Не хватает места на одном разделе? Просто переместите большую файловую систему, которая в настоящее время существует в этом разделе, в другой, обновите таблицу монтирования (в Linux /etc /fstab, может отличаться в других * nixes), чтобы указать соответствующий каталог на новое физическое устройство, и назовите его день. Или разделите файловую систему на две, переместив большой каталог в файловую систему на новом устройстве хранения, и снова просто обновите таблицу монтирования. Переходите на архитектуру хранения на основе SAN, а не на систему хранения на хост? То же самое. Что касается пользователей, это может быть сделано без явного нарушения чего-либо еще, кроме, возможно, короткого периода времени, в течение которого происходит фактическое перемещение данных. В частности, перед точками монтирования тома это не может быть легко сделано в среде Microsoft.

Когда вы создаете каталог /isos вы создаете каталог в корневой файловой системе, и поэтому хранение того, что входит в этот каталог, должно поддерживаться корневой файловой системой. Если позже вы поймете , что это хранилище является недостаточным, вы можете принять меры , чтобы смягчить или исправить эту ситуацию без необходимости логически перемещать файлы, создав отдельную файловую систему и вместо того, чтобы установить , что /isos и перемещение файлов в корневую директорию эта файловая система, делая их видимыми в /isos когда эта файловая система смонтирована там.

Имейте в виду, что Unix был спроектирован как многопользовательская система, в то время как Windows (и многие из базовых вариантов дизайна Windows) прослеживают свое происхождение по существу до строго однопользовательских систем. Хотя такого рода гибкость, скорее всего, не требуется в однопользовательской системе, она очень помогает в многопользовательской среде. (Не нужно, чтобы администратор прикреплял уведомление на входе в терминал, говоря:«Хорошо, все, что раньше было на D:, кроме D:\STUFF, теперь на Q:, кроме того, что было в D:\». ИГРЫ, которые теперь находятся в R:\WASTE, а D:\MATH теперь находятся в E:\ALGEBRA, ох, и я надеюсь, что я ничего не забыл "; просто перемешайте файлы, но сохраняйте логические каталоги такими же.)