Talk:Inode

message: "The kaki of a file system that makes use of the concept of inodes surprises many users who are not used to it at first:"
What does "kaki" mean?
213.94.245.1 19:50, 27 November 2005 (UTC)
replies: text: Hehe, obviously vandalism... Reverted. 70.82.141.92 01:08, 4 December 2005 (UTC)

text: I elaborated on the formal definition, and grounded it with some references. jdmartin86   —Preceding undated comment added 04:50, 25 November 2013 (UTC)
thread_title:  Kaki 

message: Where is the inode information stored?  With the file?   Or in a special directory?  — Preceding unsigned comment added by 65.189.137.114 (talk) 06:58, 20 March 2006 (UTC)
replies: text: Check this out -> Unix_File_System — Preceding unsigned comment added by 200.45.225.22 (talk) 16:04, 23 March 2006 (UTC)
replies: text: It depends on the file system type. Guy Harris (talk) 21:42, 31 May 2023 (UTC)
thread_title:  inode stored? 

message: For anyone who knows enough about it to do so, some discussion here about the balance between having enough inodes available and using up too much space when building a filesystem would be helpful.  Examples might include disk space usage and inode count for the same number of files when different -i values are used with mke2fs.  --joshua orvis 14:49, 8 January 2007 (UTC)
thread_title:  mke2fs -i 

message: The whole section seems to be a bit schizophrenic.  For example:
# inode file systems can fragment as severly[sic] as FAT based file systems, yet universally inode file systems lack deframenation tools.
# An inode file system would have to be offline to be fully defragmented on most systems -- but some online defragmenation tools exist.
The subsection about i_generation seem to really be either NFS only topics or NFS and Linux only topics.
There's also some odd comparison to FAT32 and NTFS.
I submit that this whole section should be removed.  IMHO it has, at best, dubious value.  --J3gum (talk) 18:04, 21 February 2008 (UTC)
thread_title:  Variations in inode file systems 

message: The first paragraph here appears to contradict itself: first saying that the number of inodes (and therefore max files) is fixed, but then saying that most file systems can handle unlimited files  —Preceding unsigned comment added by 82.11.19.16 (talk) 00:08, 12 March 2008 (UTC)
replies: text: I agree. I am removing the later phrase, as it is probably the incorrect one. SSPecter Talk|E-Mail ◆ 12:08, 19 March 2008 (UTC)
replies: text: Many, not all, file system types fix the number of inodes at creation time.  I've fixed the text. HughesJohn (talk) 10:36, 24 September 2008 (UTC)
thread_title:  Details 

message: In the following sentence, it is unclear which graph has N-1 edges: "This made the directory structure into an arbitrary directed graph as opposed to a directed acyclic graph (DAG), a connected graph with N-1 edges for N nodes." --Bobbozzo (talk) 21:09, 15 December 2009 (UTC)
thread_title:  Ambiguity 

message: "This made the directory structure into an arbitrary directed graph as opposed to a directed acyclic graph (DAG), a connected graph with N-1 edges for N nodes." 
Neither of these classes of graphs (arbit. directed or DAG) necessarily have N-1 edges for N nodes. 
In fact the first diagrams of the respective links in the text show counterexamples. 
|E| = |V-1| is the characterisation of a tree, if I remember correctly. 
Also this part of the text seems only marginally to do with inodes.
Chaos.squirrel (talk) 13:45, 14 June 2010 (UTC)
replies: text: I agree with Chaos.squirrel. A connected undirected graph without cycles does have N-1 edges for N nodes and is thus a tree. However, with DIRECTED graphs, two ways of getting from one node to another don't necessarily imply existence of a cycle. As it seems that a long time has passed since Chaos.squirrel's comment and noone answered to it, I will take the liberty and remove the invalid statement about DAGs myself. Czestmyr (talk) 11:15, 5 September 2010 (UTC)
thread_title:  DAG characterisation 

message: How to retrieve it ? (  df -i <device> )
How to change it  ? ( tune2fs -I <device> )
where to look the description of this procedures?  — Preceding unsigned comment added by Arsen.Shnurkov (talk • contribs) 08:53, 13 May 2012 (UTC)
thread_title:  Number of inodes on disk 

message: please use the explanation and pic from the german wiki -- 80.245.147.81 (talk) 06:57, 13 March 2013 (UTC)
thread_title:  max. Byte for a file - pic in german wiki 

message: Someone boldly revised all the occurrences in this article of 'inode' to 'i-node'.  While this might be appropriate, it probably should have had some discussion or evidence that is the majority usage (per WP:COMMONNAME).  As the editor was not registered, s/he can be excused from not also renaming the article.
As a starting point, a Google search of Unix inode indicates 696,000 occurrences while Unix i-node has 19,200,000.  Linux inode has 1,860,000 and Linux i-node has 9,300,000.  At first blush, this seems to weigh heavily in favor of i-node.
However, inspecting the results shows that Google appears to have ignored the hyphen as the first hyphen results do not show any context with a hyphenated word.  Therefore I repeated the searches with quotes around i-node.  For this Linux "i-node" returns 89,700 results and Unix "i-node" returns 81,600 results.  This strongly indicates that inode is the most common.  —EncMstr (talk) 21:47, 24 November 2013 (UTC)
thread_title:  inode vs. i-node 

message: Hello fellow Wikipedians,
I have just added archive links to  on Inode. Please take a moment to review my edit. If necessary, add  after the link to keep me from modifying it. Alternatively, you can add  to keep me off the page altogether. I made the following changes:
*Added archive http://web.archive.org/web/20160211033517/http://www.ibm.com/developerworks/linux/library/l-linux-filesystem/ to http://www.ibm.com/developerworks/linux/library/l-linux-filesystem/
When you have finished reviewing my changes, please set the checked parameter below to true or failed to let others know (documentation at ).
Cheers.—cyberbot IITalk to my owner:Online 12:59, 28 February 2016 (UTC)
thread_title:  External links modified 

message: that this article erroneously talks about a "POSIX i-node description" when in fact there is no such thing in the standard.
Stack Exchange notes that, obviously, on-disc i-nodes have no need of a device ID.
Furthermore: in on-disc i-nodes, the i-node number is not within the i-node itself, it being simply the index into the i-node array after all.
Nor, indeed, does the POSIX stat structure, with which i-node has been erroneously conflated here, contain any pointers to disc blocks.
The "POSIX description" is not POSIX, and is a confused mixture of in-memory i-nodes, on-disc i-nodes, and struct stat.
All three of these are different things; and only the last of them has anything at all to do with POSIX.
The article does not even explain the in-core/on-disc distinction, by the way.
Jonathan de Boyne Pollard (talk) 07:20, 19 August 2017 (UTC)
replies: text: Thanks Jonathan, I have added a  redirecting here. — Xavier, 16:12, 20 August 2017 (UTC)
replies: text:  I clarified that POSIX calls them file serial number, and reordered attributes as defined by the standard.  Further explanations may be still needed, for example in memory vs. on disc.  Yet, since what is disputed is whether POSIX defines inodes, I think said clarification suffices to remove the Disputed section template, so I'm going to do it. ale (talk) 16:00, 15 January 2018 (UTC)
replies: text: Thank you ale. I'm fine with removing the banner. I have slightly changed the section, following your edits. First, the second device ID is not the device ID of the underlying FS but a device ID that is only meaningful when the inode is associated to a special file (this is usually the combination of the major and minor device numbers on the majority of Unices). Second, I made it clearer that the list is actually the data returned by the stat system call, and not attributes a file "must have". — Xavier, 18:47, 15 January 2018 (UTC)
thread_title:  "POSIX description" is wrong 

message: The link in JVSANTEN reference did not take me to this website:
https://www.linux-faqs.info/general/difference-between-mtime-ctime-and-atime
Instead, it took me to this website: https://northgatevineyard.mobi/lk21/ 2600:1700:4FD0:D70:4817:4AD6:EC57:2B02 (talk) 05:20, 24 April 2023 (UTC)
replies: text: Domain names sometimes don't get renewed and get grabbed by other people.  Fortunately, the Wayback Machine preserves archives of a lot of sites, including that one, so the reference has been fixed to use an archived copy (and to mark the original as "usurped"). Guy Harris (talk) 06:33, 24 April 2023 (UTC)
thread_title:  For Reference 2. JVSANTEN - The link goes to a casino website