Жесткая ссылка/индексный дескриптор файла (Что есть такое, как пользоваться? ))

[QWERTYASDF]

К сожалению, про файловые системы очень мало чего понимаю кроме общего определения, и примера fat/fat32 )) Захотела выяснить, что такое "жесткая ссылка", зашла в "Википедию":

Жёсткой ссылкой в UNIX-подобных операционных системах называется имя файла, привязанное к уникальному индексному дескриптору файла. Таким образом, понятия «жёсткая ссылка на файл» и «имя файла» являются синонимами. Создать жёсткую ссылку в UNIX-подобных ОС можно при помощи команды ln, которая по умолчанию создаёт именно жёсткие ссылки.

Что такое имя файла относительно понятия файловой системы - что-то себе представляю...Понимаю, что жесткая ссылка - это еще одно имя файла ) Но вот что такое "индексный дескриптор файла"...Может местные знатоки смогут популярно объяснить?
Можно ли сделать жесткие ссылки в разных файловых системах, например в ext3 и ntfs?

п.с: Прошу не грубить, и не отсылать в гугл (только что оттуда). Не хотите отвечать на столь "приземленные" вопросы - дело Ваше

[Bizdelnick]

как пользоваться?

Лучше - никак. Пользуйтесь символическими.

Можно ли сделать жесткие ссылки в разных файловых системах, например в ext3 и ntfs?

Цитата из той же Википедии:

Жёсткая ссылка может создаваться только в пределах одного логического раздела

Про индексные дескрипторы та тоже статейка имеется. Попроще - см., например, тут.

[QWERTYASDF]

Просто где-то в гугле находила статью, что в разных фс с помощью каких-то хитрых маневров можно ) ну да ладно )
Спасибо )

[eddy]

fat32 не поддерживает хардлинки. В мастдае их поддерживает только ntfs. В линуксе все известные мне файловые системы жесткие ссылки поддерживают. Но, в отличие от символической ссылки жесткую вы можете сделать лишь в пределах одного раздела. Т.е. если /data у вас, к примеру, sda2, а /home - sda3, то сделать жесткую ссылку на какой-нибудь файл из /data к себе в домашнюю директорию у вас не получится.
Ну а индексный дескриптор, грубо говоря, - уникальный номер файла. В каждой директории (которая, по сути, тоже файл, но особый) содержится список имен файлов, хранящихся в ней, и иноды (т.е. дескрипторы) этих файлов. Посмотрите man 3 readdir на предмет структуры dirent.

[watashiwa_daredeska]

На диске есть куча «индексных дескрипторов» (inode). Каждый инод описывает совокупность данных (содержимого) и некоторых атрибутов, как то: owner, group, permissions, mtime, ctime, atime и т.п. У инода нет имени, есть номер.
Каталог — это, условно говоря, такой специальный файл, содержащий «каталожные карточки» (dir entries), которые ставят в соответствие имени номер инода. Один и тот же инод можно поставить в соответствие нескольким именам.
При удалении файла, удаляется только «каталожная карточка». Сам файл удаляется (освобождается инод) тогда, когда на него не ссылается больше ни одна карточка (файловая система считает число ссылок на файл). Это и есть «жёсткие ссылки». Само собой, жёсткие ссылки действуют исключительно в пределах одной ФС и не все ФС их поддерживают (в частности, fat*).

[QWERTYASDF]

Такой вопрос - а почему при создании жесткой ссылки, получаемый файл-копия занимает столько же места в каталоге, а точнее, почему он вообще занимает какое-то достаточное место? Нет, я понимаю, что его вес есть абстракция на уровне фс, но все-равно ведь по факту то...Если я например сделала ЖС на файл весом в несколько гб, то вполне понятно, что из-за нее у меня будет в разделе нехватка места для чего-нибудь еще (учитывая то, что физически данные файла не копируются, а только множатся линки на него...). Смысл тогда в этих ЖС? Т.е. это по сути получается копирование или копирование+переименование файла в пределах раздела без физического копирования данных файла, а только с изменением метаданных о его размещении?...
Верно говорю, или ошибаюсь? )

[Experementator]

При создании жёсткой ссылки нового файла не создаётся. Создаётся новое имя для уже существующего файла. Насколько я помню, вся информация о файле хранится в inode, а имя - это просто запись в каталоге (по сути, тоже файле), которая связует имя и идентификатор inode.

[QWERTYASDF]

При создании жёсткой ссылки нового файла не создаётся. Создаётся новое имя для уже существующего файла. Насколько я помню, вся информация о файле хранится в inode, а имя - это просто запись в катологе (по сути, тоже файле), которая связует имя и идентификатор inode.

Спасибо за резюме, а как насчет моего последнего вопроса? )

[Kopilov]

Сравните занятый объём из информации о всём томе с суммарным объёмом каталогов -- объём каталогов должен оказаться больше как раз на созданные хардлинки, т.к. они перебираются все подряд и суммируются.

[Experementator]

Лично мне интересен несколько другой вопрос. Задам, раз уж подняли такую тему...
Вот у нас есть хард, на нём написан его объём. Логично предположить, что производитель указывает его физический объём.
Создаём на нём файловую систему, допустим ext3, пишем какие-то файлы. Мы теперь можем посмотреть в ОС свойства нашего харда, в т.ч. free/usage.
Но ведь на харде хранится не только наша музыка/тексты/программы, но и служебная информация ФС. Тут вам и суперблок с его многочисленными копиями, и карта блоков, и карта inode, и таблица inode, да и сами inode... Причём логично предположить, что у разных ФС объём этой служебной информации будет разный.
Так какой объём харда показыает ОС? Физический? Но тогда получается, что это неверные цифры. Физический минус объём служебной информации? Но тогда получается, что фактически доступный объём харда зависит от ФС на нём.
Где я чего путаю, объясните, пожалуйста.

[watashiwa_daredeska]

Так какой объём харда показыает ОС?

ОС покажет любой, какой захотите. fdisk покажет физический объём, df покажет логический объем с учетом ограничений ФС, du может показать занимаемый логически объем, с учетом жестких ссылок, «дырявых» файлов и т.п.

Т.е. это по сути получается копирование или копирование+переименование файла в пределах раздела без физического копирования данных файла, а только с изменением метаданных о его размещении?...

Нет. Никакого копирования вообще не происходит. Просто создается еще одна именованная запись, указывающая на инод.

Представьте себе библиотеку. Есть книжка (файл), есть каталоги: по теме, по автору, по названию. В каталогах есть карточки для каждой книги. То, что на книжку имеется три карточки (в каждом из каталогов) не означает, что книжек на полках три.

[Experementator]

ОС покажет любой, какой захотите. fdisk покажет физический объём, df покажет логический объем с учетом ограничений ФС, du может показать занимаемый логически объем, с учетом жестких ссылок, «дырявых» файлов и т.п.

Точно. Спасибо.
Но логический объём, получается, зависит от ФС, да?..

[eddy]

ОС покажет любой, какой захотите. fdisk покажет физический объём, df покажет логический объем с учетом ограничений ФС, du может показать занимаемый логически объем, с учетом жестких ссылок, «дырявых» файлов и т.п.

Это точно. Легко можно сделать так, что df для какого-нибудь раздела покажет, скажем, 300Гб, а du - 5Тб. Правда, это делается искусственными методами. Но и за счет хардлинков вполне можно сделать, чтобы du раза в 2-3 превышало df
У меня, например, музыка так хранится: есть директория с музыкой и отдельно директория, куда я пишу хардлинки на новую музыку, которую еще не бэкапил. Потом, когда накопится на 2-3 болванки, записываю.

Но логический объём, получается, зависит от ФС, да?..

Если у вас ФС с "супермегажурналированием", то очень много реального дискового пространства будут занимать журналы, их копии, копии копий и служебная информация. Можно вообще сделать софтовый рейд на одном жестком диске, зазеркалировав, скажем, два раздела одинакового размера. Тогда у вас будет потеряно больше 50% емкости диска.

[watashiwa_daredeska]

Но логический объём, получается, зависит от ФС, да?..

Да. И от её настроек.

[QWERTYASDF]

Т.е. это по сути получается копирование или копирование+переименование файла в пределах раздела без физического копирования данных файла, а только с изменением метаданных о его размещении?...

Нет. Никакого копирования вообще не происходит. Просто создается еще одна именованная запись, указывающая на инод.

Представьте себе библиотеку. Есть книжка (файл), есть каталоги: по теме, по автору, по названию. В каталогах есть карточки для каждой книги. То, что на книжку имеется три карточки (в каждом из каталогов) не означает, что книжек на полках три.

Почему?? Я например копирую/переношу файл из одного каталога в другой на том-же разделе - "вставляется" в каталог назначения этот файл почти мгновенно. Соответственно, физически данные не копируются/переносятся (это уж точно заняло бы больше времени), а просто переписывается метаинформация о них т.е. соответствие инода/физического расположения полному имени файла. Но ведь это можно назвать "копированием" в пользовтельской абстракции? Ведь пользователю то все-равно до внутренней механики дела.
Ну, или объясните, каким образом файл в несколько Гбайт копируется или переносится физически максимум за несколько секунд? Последующая фоновая операция с данными? Так это было-бы заметно по монитору системы (обращение к жд) и/или по времени перезагрузки...Я не права? )

Представила. А представьте, что у полки, на которую ставятся книги, есть какой-либо номинал по вместительности, столько то книжных ячеек. И вот после заведения этих трех карточек на одну и ту-же, материально существующую книгу, по каталогу на соответствующей книжной полке становится на три ячейки меньше.

[watashiwa_daredeska]

Я например копирую/переношу файл

Так всё-таки, копируете, переносите или создаёте ссылку? Это три разные вещи. Хотя нет, перемещение (переименование) делается последовательными link/unlink.

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

Вместимость книжной полки измеряется не в ячейках, а в суммарном числе страниц книг, которые могут на ней уместиться.

И вот после заведения этих трех карточек на одну и ту-же, материально существующую книгу, по каталогу на соответствующей книжной полке становится на три ячейки меньше.

Не становится.

[QWERTYASDF]

Я например копирую/переношу файл

Так всё-таки, копируете, переносите или создаёте ссылку? Это три разные вещи. Хотя нет, перемещение (переименование) делается последовательными link/unlink.

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

Вместимость книжной полки измеряется не в ячейках, а в суммарном числе страниц книг, которые могут на ней уместиться.

И вот после заведения этих трех карточек на одну и ту-же, материально существующую книгу, по каталогу на соответствующей книжной полке становится на три ячейки меньше.

Не становится.

Ну ок, переношу. Насчет копирования сейчас точно не помню, а вот с перемещением было такое. Одно уточнение - на винде/нтфс это было )

Так это я такой пример просто привела. За полочную "ячейку" можно тогда условно принять кластер или сектор в гипотетической ситуации, когда все файлы-книги имеют размер меньше или равно одному кластеру или сектору.

Как же не становится, когда размер каталога, в котором я создала жесткую ссылку на файл, увеличился на размер этого файла? Что-то я не понимаю...

[watashiwa_daredeska]

Как же не становится, когда размер каталога, в котором я создала жесткую ссылку на файл, увеличился на размер этого файла?

Кто Вам это сказал? Выше уже обсуждалось, что размер бывает разный, смотря что и как считать.

Чтоб Вам было понятнее, продолжим пример с библиотекой. Допустим, мы взяли два ящичка с карточками из разных картотек. Что считать «размером ящичка»? Можно, например, считать суммарное число страниц в книжках, карточки которых лежат в этом ящичке. Можно переложить карточку книжки из одного в другой, тогда «размер» одного ящичка станет меньше, а второго больше. Ну и что? На полках с книгами ничего не поменялось.

[Bizdelnick]

Как же не становится, когда размер каталога, в котором я создала жесткую ссылку на файл, увеличился на размер этого файла? Что-то я не понимаю...

Ну считается так размер каталога: как сумма размеров всех файлов в нём. Потому что в принципе невозможно придумать более корректный способ. Нельзя ведь вообще не учитывать файлы, на которые есть несколько хардлинков, а с точки зрения файловой системы все хардлинки абсолютно равноправны, и посчитать только исходный не получится. Вот и выходит, что файл один, но виртуально существует в нескольких местах.

[QWERTYASDF]

Спасибо за пояснения и терпение ) Я провела эксперимент, сама своими глазами все увидела, и теперь вроде поняла (по крайней мере, больше)

[Experementator]

Это точно. Легко можно сделать так, что df для какого-нибудь раздела покажет, скажем, 300Гб, а du - 5Тб. Правда, это делается искусственными методами. Но и за счет хардлинков вполне можно сделать, чтобы du раза в 2-3 превышало df smile.gif

Оп-па. А вот, пожалуйста, поподробнее...
fdisk выдаёт физический объём, тут всё ясно, но почему может отличаться вывод du и df?..
И главное, что страшного в том, что на диске 300Гб свободно и 5Тб занято?..
Или я опять чего-то не понимаю?..

[QWERTYASDF]

Это точно. Легко можно сделать так, что df для какого-нибудь раздела покажет, скажем, 300Гб, а du - 5Тб. Правда, это делается искусственными методами. Но и за счет хардлинков вполне можно сделать, чтобы du раза в 2-3 превышало df smile.gif

Оп-па. А вот, пожалуйста, поподробнее...
fdisk выдаёт физический объём, тут всё ясно, но почему может отличаться вывод du и df?..
И главное, что страшного в том, что на диске 300Гб свободно и 5Тб занято?..
Или я опять чего-то не понимаю?..

Ну даже я вроде поняла =)
Потому, что дф, ду и т.п. может показывать более абстрактный а.к.а. "логический" объем, включая туда абстрактные сущности вроде файлов-жестких ссылок, файлов устройств и чего-нить там еще такого )) Ну как в ДОСе благодаря драйверу сжатых дисков+автоматическому их монтированию, система показывает объем диска в н-ое число раз больше его физического (фактического) размера (простите уж за аналогию))

[Sleeping Daemon]

Спасибо за пояснения и терпение ) Я провела эксперимент, сама своими глазами все увидела, и теперь вроде поняла (по крайней мере, больше)

Хотелось бы уточнить некоторые моменты.
"Жёсткая" ссылка - это ещё одно описание файла в каталоге. Символическая ссылка - это просто ссылка на описание файла.
Файл реально(физически) будет удалён только после удаления последнй "жёсткой" ссылки на файл. Если удалить файл(каталог - это то же файл) который имеет только симлинки, то он удалится физически, а симлинки будут указывать по старому нахождения описания файла, то есть в "никуда".
"Жёские" ссылки можно создавать в пределах одного раздела.
"Жёсткие" ссылки нельзя создать на каталоги.
Перемещение файла без его реального перемещения, только изменение записи о файле в другом каталоге, возможно только в пределах одного раздела.
В другом случае происходит именно физическое перемещение файла. Или можно ассоциировать это с копированием файла и удалением исходного файла.
Файловый дескриптор - это не inode. Это цифровое определение("цифровое имя") файла в момент его открытия. Есть файловые системы, которые не имеют inode, например ReiserFS.
Всё это не относится к файловым системам, используемых в windows. Там своя кухня.

[QWERTYASDF]

Хотелось бы уточнить некоторые моменты.
"Жёсткая" ссылка - это ещё одно описание файла в каталоге. Символическая ссылка - это просто ссылка на описание файла.
Файл реально(физически) будет удалён только после удаления последнй "жёсткой" ссылки на файл. Если удалить файл(каталог - это то же файл) который имеет только симлинки, то он удалится физически, а симлинки будут указывать по старому нахождения описания файла, то есть в "никуда".
"Жёские" ссылки можно создавать в пределах одного раздела.
"Жёсткие" ссылки нельзя создать на каталоги.
Перемещение файла без его реального перемещения, только изменение записи о файле в другом каталоге, возможно только в пределах одного раздела.
В другом случае происходит именно физическое перемещение файла. Или можно ассоциировать это с копированием файла и удалением исходного файла.

Ну это итак все уже очевидно, и очевидно, что это очевидно )

Файловый дескриптор - это не inode. Это цифровое определение("цифровое имя") файла в момент его открытия. Есть файловые системы, которые не имеют inode, например ReiserFS.
Всё это не относится к файловым системам, используемых в windows. Там своя кухня.

А вот здесь можно поконкретнее? Оно создается только на момент открытия файла? Так как-же тогда с ним чего-то ассоциируется на постоянной основе? (имя файла-жесткая ссылка к дескриптору). Или Вы говорите не об "индексном дескрипторе файла", о котором я спрашивала относительно ЖС, а о чем-то ином? Или же Файловый дескриптор при открытии файла возникает и при имении и отсутствии инода (в этом случае он как-бы равен ему, ?), возникает в любом случае, а в Википедии определение ЖС дается в частном случае имения инода? Или как? Опять чего-то запуталась )

[t.t]

Такой вопрос - а почему при создании жесткой ссылки, получаемый файл-копия занимает столько же места в каталоге, а точнее, почему он вообще занимает какое-то достаточное место? Нет, я понимаю, что его вес есть абстракция на уровне фс, но все-равно ведь по факту то...Если я например сделала ЖС на файл весом в несколько гб, то вполне понятно, что из-за нее у меня будет в разделе нехватка места для чего-нибудь еще (учитывая то, что физически данные файла не копируются, а только множатся линки на него...). Смысл тогда в этих ЖС? Т.е. это по сути получается копирование или копирование+переименование файла в пределах раздела без физического копирования данных файла, а только с изменением метаданных о его размещении?...
Верно говорю, или ошибаюсь? )

Shell

$ mkdir 0 $ dd if=/dev/zero of=0/1 bs=1024 count=512 512+0 records in 512+0 records out $ ls -l 0 -rw-r--r-- 1 user users 524288 Apr 9 07:32 1 $ du -s 0 520 0 $ ln 0/1 0/2 $ ls -l 0 -rw-r--r-- 2 user users 524288 Apr 9 07:32 1 -rw-r--r-- 2 user users 524288 Apr 9 07:32 2 $ du -s 0 520 0

Я ответил на Ваш вопрос?

[t.t]

Shell

$ ls -l 0 -rw-r--r-- 1 user users 524288 Apr 9 07:32 1

Shell

$ ls -l 0 -rw-r--r-- 2 user users 524288 Apr 9 07:32 1 -rw-r--r-- 2 user users 524288 Apr 9 07:32 2

Кстати, цифра во второй колонке в выводе ls -l и есть количество жёстких ссылок ("каталожных карточек") на этот файл.

[t.t]

Но и за счет хардлинков вполне можно сделать, чтобы du раза в 2-3 превышало df

Нельзя, см. выше: du учитывает жёсткие ссылки при подсчёте.

[eddy]

Нельзя, см. выше: du учитывает жёсткие ссылки при подсчёте.

Точно, это я стормозил.
Зато есть такой фокус:

Код: Выделить всё

[09.04 09:21 ~/tmp]
du -hs
839M    .
[09.04 09:21 ~/tmp]
ls -lh tmp
-rw-r--r-- 1 eddy eddy 64G 2010-04-09 09:20 tmp
[09.04 09:22 ~/tmp]
du tmp
65M    tmp

Получился 64-гигабайтный файл в директории, размер которой - 839Мб, а сам файл на диске занимает 65Мб

[Frank]

Чтобы понять (прочувствовать), что такое жёсткая ссылка (хардлинк) и чем оно отличается от мягкой, следует сделать такой эксперимент:
- создать файл какой-нибудь
- создать мягкую ссылку на него
- создать жёсткую ссылку на него
- удалить файл
Что имеем? Мягкая ссылка "поломалась", так как она ссылается на имя файла, а жёсткая ссылка по-прежнему работает, так как ссылается на инод (индексный дескриптор файла). Файл (как последовательность байтов) не будет удалён с носителя до тех пор, пока счётчик жёстких ссылок на него не равен нулю. Можно в первом приближении считать, что жёсткая ссылка - это и есть имя файла.

[Portnov]

Можно в первом приближении считать, что жёсткая ссылка - это и есть имя файла.

Именно что не в первом приближении, а так оно и есть. Имя файла - это и есть жёсткая ссылка на него.

... это не факт, а так оно и есть на самом деле...