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.
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 3 years ago.
Improve this question
According to kernel.org there is the possibility to store dentries in trees instead of lists but you need to enable this flag (EXT4_INDEX_FL) in the inode structure. I this enabled by default or I have to format my partition with some flags?
I need to store lots of small files (same old problem) of about 130k each and I understood that this will help to speed up lookup and also that it is recommended to store those files in a 2 level directories hierarchy. Is there something else I need to consider so that this doesn't blow up if want to store something close to 60.000.000 of this kind of files ? (maybe some other values for block size, number of blocks in a group)
This option is referred to by the e2fsprogs suite as dir_index. It's enabled by default, and you can verify that it's enabled on a file system by running tune2fs -l DEVICE as root.
It is indeed recommended that you shard your files manually so that you don't have a huge number of files in the same directory. While using B-trees makes the operation O(log n) instead of O(n), for large numbers of files, the operation can still be expensive.
If you know you're going to be creating a large number of files, you can set the inode ratio to 4096 with the -i option; this will create a larger number of inodes so that you can hold more files. You can also see common settings for a large number of situations in /etc/mke2fs.conf.
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 7 years ago.
Improve this question
I'm running shred against blockdevice with couple of etx4 filesystems on it.
The blockdevices are virtual drives - RAID-1 and RAID-5. Controller is PERC H710P.
command
shred -v /dev/sda; shred -v /dev/sdc ...
I can understand from shred man(info) page that shred might be no effective on journal filesystems but only when shredding files.
Anyone can please explain whether is shredding against blockdevice safe way to destruct all data on it?
This is a complex issue.
The only way that is 100% effective is physical destruction. The problem is that the drive firmware can mark sectors as bad and remap them to a pool of spares. These sectors are effectively no longer accessible to you but the old data may be recoverable from those sectors by other means (such as an alternate firmware or physically removing the platters).
That being said, running shred on the block device does not have the issues due to journaling.
The problem with journaling is that for partial overwrites to be recoverable you cannot actually overwrite the original data, so the overwrite of the file takes place in a second physical location, leaving the first in tact. Writing directly to the block device is not subject to journaling.
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 1 year ago.
Improve this question
Is there any way to store any data in Linux tmp directory. As i know Linux clear its /tmp directory when system is rebooted. But I want to store data permanently.
Like #bereal said, this defeats the purpose of the /tmp directory. Let me quote the Linux Filesystem Hierarchy Standard:
The /tmp directory must be made available for programs that require temporary files.
Programs must not assume that any files or directories in /tmp are preserved between invocations of the program.
You'll find a better place to store permanent data.
Since it's linux you are free to do what you want to do (as root). When /tmp is cleared depends on your system and can be changed; there is no particular magic involved. A good summary seems to be here: https://serverfault.com/questions/377348/when-does-tmp-get-cleared.
Of course if you are root you can set up an entirely different global directory, say "/not-quite-tmp" or such. But I assume that some progs not under your control write to tmp and you want to inspect or in any case persist those files.
While you are trying to do wrong things, it’s still possible.
/tmp directory is cleared accordigly to TMPTIME setting. The default is apparently 0, what means “clear on every startup”.
The value might be changed in /etc/default/rcS (value is to be set in days.)
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 used the mv command on a file then this message appeared:
mv 'file.tar': Disk quota exceeded
but now there is a file.tar in both the new location and the old location. They're different sizes and I have no idea what the size of the original file was. (There are a lotttt of files in this tarball)
Can I just delete the file that failed to get moved or will I lose part of my original data if I do that?
When Unix/Linux mv(1)-es a file, if source and destination are on the same filesystem, it is just a rename. This can't give an "out of space" message (at least not AFAICS). When moving a file between filesystems (different partitions or disks), what is done is to copy the source to the destination, and when the operation suceeds, the source is deleted. During the copying the destination filesystem can run out of space, and the source won't be deleted. It is strange that the (partial) destination stays in your case, in my experience mv cleans that up (but it's been a while...). In this case the user to which the target file belongs is running out of allowed disk space.
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'm a fresh man in Linux.When learning the file system in Linux,I got confused with 3 kind of 3 time status,which are atime,ctime,mtime.What are they,how to distinguish them and what operation to files will cause their changing?
atime: The last time the file was accessed
ctime: The last time the inode was changed
mtime: The last time the file data was changed
An inode is a collection of file metadata. While they can vary somewhat from filesystem to filesystem, a standard inode has the file's permissions, ownership, size, link count and a pointer structure indicating where the file's data reside on the disk. The inode doesn't contain actual file data and doesn't know the file's name, so the ctime is only updated when permissions, ownership, or links change for an inode.
Many filesystems will let you turn off some or all of these timestamps for performance reasons.