From ArchWiki
Jump to: navigation, search

inodes and hardlinks

I created small EXT4 file system in 512MB file and mounted it in /mnt/ram

On fresh system df -i | grep ram gives:

/dev/loop0                    32768      11    32757    1% /mnt/ram

After echo "aaa" >> aaa

/dev/loop0                    32768      12    32756    1% /mnt/ram

It looks ok.

I created bash script to make hardlinks to aaa file:

for i in {1..50000}
    ln /mnt/ram/aaa /mnt/ram/$i

Amount of created hardlinks is greater than free inodes, so this operation should failed, but it doesen't...

find /mnt/ram/ -type f | wc -l
df -i | grep ram
/dev/loop0                    32768      12    32756    1% /mnt/ram

So is senstens bellow actual? "Warning: If you make a heavy use of symbolic or hard links, e.g. you use a backup scheme leveraging rsync --link-dest feature (rsnapshot, BackupPC, backintimeAUR...), make sure to keep the inode count high enough with a low bytes-per-inode ratio, because while not taking more space every new hardlink consumes one new inode and therefore the filesystem may run out of them quickly."

Brii (talk) 09:08, 27 June 2016 (UTC)

Nice test, but I think it only works because the links are shorter than 60-byte? See [1]. --Indigo (talk) 09:32, 27 June 2016 (UTC)
OK, so I put 129 bytes into aaa file and repeat creating 50000 hardlinks and everything is OK - I've got 50001 files and 12 inodes in use... The same situation with files: size 2080 bytes and 4794 bytes Brii (talk) 09:53, 27 June 2016 (UTC)
It does not matter how large the file is. The hard link is basically as large as its file name. -- Lahwaacz (talk) 10:11, 27 June 2016 (UTC)
Is my conclusion right - hardlinks doesen't affect free inode pool? Brii (talk) 12:17, 27 June 2016 (UTC)
Yes, you're right. If you look at the df output (i.e. without -i) when the filesystem is empty and after the hardlinks are created, you'll see a difference in the blocks usage. -- Lahwaacz (talk) 16:46, 27 June 2016 (UTC)
I created aaa file (size 2MB)
root@dc7900:/mnt/ram# ls -l
razem 2028
-rw-r--r-- 1 root root 2064384 cze 28 08:13 aaa
drwx------ 2 root root   12288 cze 28 08:10 lost+found

root@dc7900:/mnt/ram# df | grep ram
/dev/loop0                    487652      5429   452527   2% /mnt/ram

Then I run script to make 50000 hardlinks.

root@dc7900:/mnt/ram# find /mnt/ram/ -type f | wc -l
root@dc7900:/mnt/ram# df | grep ram
/dev/loop0                    487652      5429   452527   2% /mnt/ram

No extra blocks were used so is logical for me (idea of hardlinks based on that). Where is stored information about hardlinks if hardlinks doesn't affect number of free indoes nor blocks? Brii (talk) 06:18, 28 June 2016 (UTC)

As I said before, hardlinks take as much space as its name. In your case the name is only a couple of bytes, so you just don't see the difference. If you create links with much longer name, e.g. for i in {1..50000}; do ln foo hardlinks/$(sha256sum <<< $i | cut -d' ' -f1); done, the difference is about 5 MB:
# empty disk:
Filesystem     1K-blocks      Used Available Use% Mounted on
/dev/loop0        499656       396    462564   1% /media/testfile
# with one empty file, one directory and 50000 hardlinks:
/dev/loop0        499656      5544    457416   2% /media/testfile
-- Lahwaacz (talk) 06:43, 28 June 2016 (UTC)
It's clear now, thanks :-) Brii (talk) 06:46, 28 June 2016 (UTC)

Replacing dead link

In [2] a dead link was deleted.

The (deleted) link was pointing to a draft of a document.

I would suggest re-adding a link, this time pointing to a more-permanent document (not a draft).

Potential alternatives would be:

Ady (talk) 20:51, 14 October 2016 (UTC)

I actually did find an updated version of the linked document: . The reason I still removed the link was because the paragraph with the link contained basically the same text as the linked SLES doc, so I didn't see any need for it. If you think one of these links could be useful, feel free to add it back. -- nl6720talk 13:47, 16 October 2016 (UTC)
Generally speaking, when a command or a behavior is questioned / put in doubt, sometimes users edit the wiki pages according to their own experiences (whether they performed the steps correctly or not). Having some kind of sources/resources/context/links for the information posted in the wiki might help clarify the steps / commands / disagreements.
Considering that the wiki text replicates (only) the relevant practical paragraphs of what the original document states, a link to the opensuse document functions as a "reference". The Arch wiki usually doesn't make use of "references" (as oppose to Wikipedia, which almost "demands" them), so I am not sure what should be done in this case. Now that valid/current links are posted here, I'll leave it for someone else to decide Ady (talk) 14:33, 16 October 2016 (UTC)
If a reference is needed, linking directly to the most upstream documentation, i.e. ext4(5) or should always be the preferable solution: all the documents linked above seem not to add anything to these two. A different thing would be linking to articles (possibly from reputable sources) that offer more in-depth explanations, for example [3] in this case. — Kynikos (talk) 10:48, 17 October 2016 (UTC)