summaryrefslogtreecommitdiffstats
path: root/include/linux/fs.h
diff options
context:
space:
mode:
authorKalin KOZHUHAROV <kalin@thinrope.net>2006-04-01 01:41:22 +0200
committerAdrian Bunk <bunk@stusta.de>2006-04-01 01:41:22 +0200
commit8ba8e95ed14a2771bbcb43300feda094f298853e (patch)
tree8f487c4f31175eea531fbf7305c91819eca17bec /include/linux/fs.h
parent36a891b67f95fd5e1442fc0f7f953809b94b3fbc (diff)
downloadop-kernel-dev-8ba8e95ed14a2771bbcb43300feda094f298853e.zip
op-kernel-dev-8ba8e95ed14a2771bbcb43300feda094f298853e.tar.gz
Fix comments: s/granuality/granularity/
I was grepping through the code and some `grep ganularity -R .` didn't catch what I thought. Then looking closer I saw the term "granuality" used in only four places (in comments) and granularity in many more places describing the same idea. Some other facts: dictionary.com does not know such a word define:granuality on google is not found (and pages for granuality are mostly related to patches to the kernel) it has not been discussed as a term on LKML, AFAICS (=Can Search) To be consistent, I think granularity should be used everywhere. Signed-off-by: Kalin KOZHUHAROV <kalin@thinrope.net> Signed-off-by: Adrian Bunk <bunk@stusta.de>
Diffstat (limited to 'include/linux/fs.h')
-rw-r--r--include/linux/fs.h2
1 files changed, 1 insertions, 1 deletions
diff --git a/include/linux/fs.h b/include/linux/fs.h
index 4ed7e60..1e9ebab 100644
--- a/include/linux/fs.h
+++ b/include/linux/fs.h
@@ -864,7 +864,7 @@ struct super_block {
*/
struct mutex s_vfs_rename_mutex; /* Kludge */
- /* Granuality of c/m/atime in ns.
+ /* Granularity of c/m/atime in ns.
Cannot be worse than a second */
u32 s_time_gran;
};
OpenPOWER on IntegriCloud