Closed. This question is off-topic. It is not currently accepting answers.
Want to improve this question? Update the question so it's on-topic for Stack Overflow.
Closed 11 years ago.
Improve this question
What is the size of the hardlink in Linux? Will it be the size of the inode? If I have two of them?
Thanks in advnace for any explanation, I tried to google it, but didn't find anything
A hard link reuses the inode, but requires a separate directory entry, which takes up 8 bytes plus the length of the file name in ext2. There may be other costs associated, such as when directory indexing is used, also, directories grow by entire blocks.
Think of a hard link as just another name for a file. If a file has 1000 hard links, that just means that it has 1000 different directory entries associated with it, all with potentially different names. For example, if you had 1000 different names, you would still only be one person. You'd take up the same amount of space no matter how many names you had. You'd just have a bit more paperwork for each additional name.
Related
Closed. This question does not meet Stack Overflow guidelines. It is not currently accepting answers.
This question does not appear to be about a specific programming problem, a software algorithm, or software tools primarily used by programmers. If you believe the question would be on-topic on another Stack Exchange site, you can leave a comment to explain where the question may be able to be answered.
Closed 9 years ago.
Improve this question
I understand detnries are about saving time by not accessing the disk to get a file's inode.
All the sources I read depict how an inode is found using the dentries.
None of them really describe how an inode is found if we have no dentries to it.
Let's say I want to access /home/dlv/src.c and the dentry cache is empty.
How would the OS create the new dentries?
Can you explain the rough mechanism? (from searching the disk and creating the dentry and setting its fields etc..).
Thank you,
Dolev.
The root directory entry of a file system is usually either in a well-known place, or has a well-known inode number, or the inode number for it is stored in the superblock or other file system metadata. From there, the blocks containing the directory entries for the root are scanned to find home - that dir entry will contain the inode number for home. The blocks referenced by that inode are then scanned to get the directory entries from /home and search for dlv. Repeat until you get to the last directory entry in the path, and scan that directory's inode for directory entries matching the file in question.
Thinking about that process for an extremely deeply nested file on a disk that takes 10ms per access should give you a good idea of the motivation for the directory entry cache... Finding a single deeply-nested file on disk can easily take hundreds of disk accesses.
Closed. This question is off-topic. It is not currently accepting answers.
Want to improve this question? Update the question so it's on-topic for Stack Overflow.
Closed 9 years ago.
Improve this question
How to find the number of times particular file has been modified in given time range i.e in last 2 days in Unix client?
As seen in UNIX & Linux Stackexchange
Linux offers three timestamps for files: time of last access of
contents (atime), time of last modification of contents (mtime),
and time of last modification of the inode (metadata, ctime). So,
no, you cannot. The directory's mtime corresponds to the last file
creation or deletion that happened, though.
So you cannot know neither the creation time, neither the history of the modifications.
The linux kernel uses inode for files in filesystems these inodes do not log changes in the filesystem, you can however ask for the last change through mtime example find testfile -mtime 2 this will tell you if the file has changed in the last 48 hours.
You are looking the log changes to the file, you could use inotify for that. Or the inotifywait tool. Which let's you efficiently wait for changes in a file.
I suggest inotifywait.
Closed. This question is off-topic. It is not currently accepting answers.
Want to improve this question? Update the question so it's on-topic for Stack Overflow.
Closed 9 years ago.
Improve this question
This question has been flagged as irrelevant so I guess this has no real worth to anyone so I tried removing the question but the system won't let me so I am now truncating the content of this post ;)
I think you need to run the actual numbers for both scenarios:
On the fly
how long does one image take to generate and do you want the client to wait that long
do you need to pay by cpu utilization, number of CPUs etc. and what will this cost for X images thumbnailed Y times over 1 year
Stored
how much space will this use and what will it cost
how many files are there? Is the number bigger than the number of inodes in the destination file system, or is the total estimated size bigger than the file system
It^s mostly an economics question, there is no general yes/no answer. When in doubt, I'd probably go with storing them since it's a computation intensive tasks and it's not very efficient to do it over and over again. You could also do a hybrid solution like generate a thumbnail on the fly when it is first requested, then cache it until it wasn't used for certain a number of days.
TL;DR: number of inodes is probably your least concern.
Closed. This question is off-topic. It is not currently accepting answers.
Want to improve this question? Update the question so it's on-topic for Stack Overflow.
Closed 10 years ago.
Improve this question
I have the following /etc/exports config for my NFS server.
/root/share *(rw,fsid=0,no_root_squash)
/root/share/music anne(rw,no_root_squash) alex(rw,no_root_squash)
/root/share/video anne(rw,no_root_squash) alex(ro,no_root_squash)
I want anne to have rw access to both directories. I want alex to have only ro access to /root/share/video. The problem with my current config is that they both have rw access.
If I change the first line to
/root/share *(ro,fsid=0,no_root_squash)
It overwrites every other line and makes all directories read-only.
How can I make the first line take effect only on /root/share ?
Thank you.
You are very confused about what constitutes an exported filesystem. /etc/exports does not contain an Access Control List - not really. It contains a list of independent filesystems and how they should be exported.
Each entry is completely separate from each other and the export name matching is exact, not recursive - if alex mounts /root/share only the first entry will be used. In the same vein, alex cannot mount /root/share/misc directly because it is not an exported directory.
Closed. This question is off-topic. It is not currently accepting answers.
Want to improve this question? Update the question so it's on-topic for Stack Overflow.
Closed 10 years ago.
Improve this question
drwxr-xr-x 2 vivekray vivekray 4096 2012-01-02 14:09 Templates
what is the meaning of 2.
if you have some time please reply me thanx.
As the other answers have explained, the number is a count of hard links to the file. However, since your "file" is a directory, the meaning is a little different than usual.
Directories in Unix-like systems always have at least two links to them. One is the directory's entry in its parent directory and the other is the "." entry in its own listing. If there are any sub-directories within a directory, each one caused an additional link to its parent from its ".." entry.
So the extra bit of info you can get from that number is that Templates has no sub-directories.
It is the number of hard links referencing that file/blob of data. The 2 means that there are two different names (Templates being one of those) for the same file.
Note that this only works for hard links and not symbolic links (links created with ln -s). Also note that the other name of that file will also have a count of 2.
It's the number of hard links to the file.
Number of links: Second field specifies the number of links for that file. In this example, 2 indicates that there are 2 links to this directory entry.