confused on hardlinks

Hello... probably simple question, but I'm confused.

Hard links... I have some folder called /home/peon/bin  which has a few binaries.

I have another folder called /home/newpeon/bin that will contain the exact same binaries

So I used the command   cp -al /home/peon/bin/* /home/newpeon/bin/  to make links, right?

Well... everything went fine, but look...

$ du --max-depth=1 /home/peon/bin

8       ./.ssh
22272    ./bin

$ du --max-depth=1 /home/newpeon/bin

8       ./.ssh
22272    ./bin

They are the same!  If they are hardlinks, shouldn't one be MUCH smaller???

Ok, so then to verify that they are indeed hardlinks I do the following

ls -i /home/peon/bin  (and the same for newpeon) and sure enough the inodes are all identical.

Same inodes but they both take up space??

What am I missing here?

Thanks.
s_mackAsked:
Who is Participating?

[Product update] Infrastructure Analysis Tool is now available with Business Accounts.Learn More

x
I wear a lot of hats...

"The solutions and answers provided on Experts Exchange have been extremely helpful to me over the last few years. I wear a lot of hats - Developer, Database Administrator, Help Desk, etc., so I know a lot of things but not a lot about one thing. Experts Exchange gives me answers from people who do know a lot about one thing, in a easy to use platform." -Todd S.

GnsCommented:
Do "ls -l home/newpeon/bin /home/peon/bin". Pay attention to the link count field (the second one, after the -rwx------). If these are hard linked files, they will be regular files with a link count greater than 1. As you ls -i show, the files are in fact just references to the same inodes in different directories.

This is obvious to you&me ... but not to du.
du just blithely counts what's in the directory. After all, it would be even more wrong to report it as 0 size:-).
The obvious followup "Can't I rely on du?" would then have an equally obvious answer "not further than you can throw it."...:-).

df wouldn't change though. Apart for the allocation of the directory.

-- Glenn
GnsCommented:
BTW, we're touching on the reason why you cannot do hardlinks past the filesystem boundary here... You might have the same inode on separate fs's, so it would be a real nono to allow...

-- Glenn
s_mackAuthor Commented:
hmm... so how does one find an accurate count of how much space a user is using?
Determine the Perfect Price for Your IT Services

Do you wonder if your IT business is truly profitable or if you should raise your prices? Learn how to calculate your overhead burden with our free interactive tool and use it to determine the right price for your IT services. Download your free eBook now!

s_mackAuthor Commented:
and... what is the point of the -l flag with du???  If it counts the links anyway, why have an option specifically for counting links?
guynumber5764Commented:
<I>hmm... so how does one find an accurate count of how much space a user is using?</I)

I would use the owner of the file rather than the path as my criteria.  But that still doesn't solve your problem.  We'll get back to why in a sec.

I think that you are confusing hard links with symbolic links.  The difference quickly becomes apparent when peon deletes his bin directory.  A symbolic link would get all noodled because the linked file no longer exists.  A hard link would be fine because it <b>is</b> the linked file under a different filename (the link count would just get decremented).  the trick is that the original directory entry and the hard link created later are totally symmetrical.

As for du -l, the option affects how it handles encountering more than one occurrence of the same file (through multiple hard links).  An example explains it best (x, y, z are hard links to the same file)...

[~/tmp]$ ls -l
total 1440
lrwxrwxrwx    1 peon         peons           1 Oct 29 00:04 s -> x
-rw-------          3 peon          peons      486331 Sep 18 18:08 x
-rw-------          3 newpeon   peons      486331 Sep 18 18:08 y
-rw-------          3 peon          peons      486331 Sep 18 18:08 z
[~/tmp]$ du .
480K    .
[~/tmp]$ du -l .
1.5M    .

Getting back to the original question of distribution look at the above directory listing and see if you can decide who is supposed to get dinged for the space occupied by x, y, and z and how badly.  Just to make it fun, the original directory entry was deleted and belonged to someone else (it really was).

guynumber5764Commented:
Oops sorry about the tags...thought I was on /. for a sec...
E.
GnsCommented:
> BTW, we're touching on the reason why you cannot do hardlinks past the filesystem boundary here... You might have the same inode on separate fs's, so it would be a real nono to allow...
Not to mention that there is no provision in any fs to reference an inode on another fs... other than symbolically (covered nicely by guynumber5764... Thanks BTW for the nice illustration of why du will never know what to do with hard links).

-- Glenn
s_mackAuthor Commented:
> BTW, we're touching on the reason why you cannot do hardlinks past the filesystem boundary here... You might have the same inode on separate fs's, so it would be a real nono to allow...

/home is the fs in question.  so same fs.  each user gets a chrooted jail with their own bin, lib, etc. those are the ones that are hardlinked.  There's a "template" peon that I cp'd all the files to... then cp -al'd all those to the other peons.

ok ok... this is where it becomes apparant that you guys have an understanding of what you are talking about, and I'm still stuck on "if Johnny has two apples and he eats one...."

Forget the why's for a second... how can I be convinced that I am in fact saving space by using cp -al instead of just cp?  Really, which user gets dinged for it is insignificant because the space taken up by the "shared" directories (bin and lib) is .0008% of their total allowed space. But with 64,000 peons... it ads up.  So I just wanted to be sure that I was using less space.

And for some strange reason, df has been #%@#@ up for ages on this system.  It has reported that the /home fs is 36% full since time began.  At one point I'm sure it was, but then we deleted the entire /home and it was still 36% full... filled it right up to the point of disk error... still 36% full.. with the exact number of kb reportedly being used.   So I've given up on df and was hoping du could do what I want.
GnsCommented:
> Forget the why's for a second... how can I be convinced that I am in fact saving space by using cp -al instead of just cp?  Really, which user gets dinged for it is
> insignificant because the space taken up by the "shared" directories (bin and lib) is .0008% of their total allowed space. But with 64,000 peons... it ads up.  So I just
> wanted to be sure that I was using less space.
You answered that yourself! With your ls -i, which shows that there has only been allocated one inode (well..), and the ls -l show (link count _huge_ in your case then:-) that too... If you have that kind of setup, the space savings would be ... huge.

> And for some strange reason, df has been #%@#@ up for ages on this system.  It has reported that the /home fs is 36% full since time began.  At one point I'm sure
> it was, but then we deleted the entire /home and it was still 36% full... filled it right up to the point of disk error... still 36% full.. with the exact number of kb
> reportedly being used.   So I've given up on df and was hoping du could do what I want.

df should work... Have you fsck'd it recently? Did you run out of space or inodes?

-- Glenn
s_mackAuthor Commented:
you can run out of  inodes?!?!?!
GnsCommented:
Yes. On most filesystems this is something you set at creation time (nocely obfuscated as "inode density" parameters:-).
Check out the fs you are using (man mke2fs for ext2/ext3...).

-- Glenn
guynumber5764Commented:

df should work fine but remember it works with volumes (partitions) not directories.  

If there is a discrepancy between it and du make sure your volumes are mounted the way that you think they are.  

As an experiment do a df -v then create a (real not linked) large file and df -v again.  One of your volumes (not always the one you expect) will show a difference in available space.  If the file shows up on the / volume instead of the /home volume then you have to empty the /home directory and then mount /home.


guynumber5764Commented:
To answer your 2nd question: "how can I be convinced"... du -l /home should be different from from du /home.  The difference is the amount of space you are saving.

Experts Exchange Solution brought to you by

Your issues matter to us.

Facing a tech roadblock? Get the help and guidance you need from experienced professionals who care. Ask your question anytime, anywhere, with no hassle.

Start your 7-day free trial
It's more than this solution.Get answers and train to solve all your tech problems - anytime, anywhere.Try it for free Edge Out The Competitionfor your dream job with proven skills and certifications.Get started today Stand Outas the employee with proven skills.Start learning today for free Move Your Career Forwardwith certification training in the latest technologies.Start your trial today
Linux

From novice to tech pro — start learning today.