fix "seperate" typos in comments
s/seperate/separate Signed-off-by: Anand Gadiyar <gadiyar@ti.com> Signed-off-by: Jiri Kosina <jkosina@suse.cz>
This commit is contained in:
parent
7d7fb0e6eb
commit
a8cd4561ea
7 changed files with 14 additions and 14 deletions
|
@ -59,7 +59,7 @@ Levels
|
|||
------
|
||||
|
||||
Garbage collection (GC) may fail if all data is written
|
||||
indiscriminately. One requirement of GC is that data is seperated
|
||||
indiscriminately. One requirement of GC is that data is separated
|
||||
roughly according to the distance between the tree root and the data.
|
||||
Effectively that means all file data is on level 0, indirect blocks
|
||||
are on levels 1, 2, 3 4 or 5 for 1x, 2x, 3x, 4x or 5x indirect blocks,
|
||||
|
@ -67,7 +67,7 @@ respectively. Inode file data is on level 6 for the inodes and 7-11
|
|||
for indirect blocks.
|
||||
|
||||
Each segment contains objects of a single level only. As a result,
|
||||
each level requires its own seperate segment to be open for writing.
|
||||
each level requires its own separate segment to be open for writing.
|
||||
|
||||
Inode File
|
||||
----------
|
||||
|
@ -106,9 +106,9 @@ Vim
|
|||
---
|
||||
|
||||
By cleverly predicting the life time of data, it is possible to
|
||||
seperate long-living data from short-living data and thereby reduce
|
||||
separate long-living data from short-living data and thereby reduce
|
||||
the GC overhead later. Each type of distinc life expectency (vim) can
|
||||
have a seperate segment open for writing. Each (level, vim) tupel can
|
||||
have a separate segment open for writing. Each (level, vim) tupel can
|
||||
be open just once. If an open segment with unknown vim is encountered
|
||||
at mount time, it is closed and ignored henceforth.
|
||||
|
||||
|
|
|
@ -391,7 +391,7 @@ static struct clk clk_hsmmc = {
|
|||
|
||||
/* i2s_eplldiv
|
||||
*
|
||||
* This clock is the output from the I2S divisor of ESYSCLK, and is seperate
|
||||
* This clock is the output from the I2S divisor of ESYSCLK, and is separate
|
||||
* from the mux that comes after it (cannot merge into one single clock)
|
||||
*/
|
||||
|
||||
|
|
|
@ -97,7 +97,7 @@ extern void s3c_gpiolib_add(struct s3c_gpio_chip *chip);
|
|||
* others = Special functions (dependant on bank)
|
||||
*
|
||||
* Note, since the code to deal with the case where there are two control
|
||||
* registers instead of one, we do not have a seperate set of function
|
||||
* registers instead of one, we do not have a separate set of function
|
||||
* (samsung_gpiolib_add_4bit2_chips)for each case.
|
||||
*/
|
||||
extern void samsung_gpiolib_add_4bit_chips(struct s3c_gpio_chip *chip,
|
||||
|
|
|
@ -181,7 +181,7 @@ struct ehci_hcd_omap {
|
|||
void __iomem *ehci_base;
|
||||
|
||||
/* Regulators for USB PHYs.
|
||||
* Each PHY can have a seperate regulator.
|
||||
* Each PHY can have a separate regulator.
|
||||
*/
|
||||
struct regulator *regulator[OMAP3_HS_USB_PORTS];
|
||||
};
|
||||
|
|
|
@ -12,7 +12,7 @@
|
|||
* Atomic dir operations
|
||||
*
|
||||
* Directory operations are by default not atomic. Dentries and Inodes are
|
||||
* created/removed/altered in seperate operations. Therefore we need to do
|
||||
* created/removed/altered in separate operations. Therefore we need to do
|
||||
* a small amount of journaling.
|
||||
*
|
||||
* Create, link, mkdir, mknod and symlink all share the same function to do
|
||||
|
|
|
@ -704,7 +704,7 @@ static inline gc_level_t expand_level(u64 ino, level_t __level)
|
|||
u8 level = (__force u8)__level;
|
||||
|
||||
if (ino == LOGFS_INO_MASTER) {
|
||||
/* ifile has seperate areas */
|
||||
/* ifile has separate areas */
|
||||
level += LOGFS_MAX_LEVELS;
|
||||
}
|
||||
return (__force gc_level_t)level;
|
||||
|
|
|
@ -50,9 +50,9 @@ static inline void check_##type(void) \
|
|||
* 12 - gc recycled blocks, long-lived data
|
||||
* 13 - replacement blocks, short-lived data
|
||||
*
|
||||
* Levels 1-11 are necessary for robust gc operations and help seperate
|
||||
* Levels 1-11 are necessary for robust gc operations and help separate
|
||||
* short-lived metadata from longer-lived file data. In the future,
|
||||
* file data should get seperated into several segments based on simple
|
||||
* file data should get separated into several segments based on simple
|
||||
* heuristics. Old data recycled during gc operation is expected to be
|
||||
* long-lived. New data is of uncertain life expectancy. New data
|
||||
* used to replace older blocks in existing files is expected to be
|
||||
|
@ -117,7 +117,7 @@ static inline void check_##type(void) \
|
|||
#define pure_ofs(ofs) (ofs & ~LOGFS_FULLY_POPULATED)
|
||||
|
||||
/*
|
||||
* LogFS needs to seperate data into levels. Each level is defined as the
|
||||
* LogFS needs to separate data into levels. Each level is defined as the
|
||||
* maximal possible distance from the master inode (inode of the inode file).
|
||||
* Data blocks reside on level 0, 1x indirect block on level 1, etc.
|
||||
* Inodes reside on level 6, indirect blocks for the inode file on levels 7-11.
|
||||
|
@ -204,7 +204,7 @@ SIZE_CHECK(logfs_segment_header, LOGFS_SEGMENT_HEADERSIZE);
|
|||
* @ds_crc: crc32 of structure starting with the next field
|
||||
* @ds_ifile_levels: maximum number of levels for ifile
|
||||
* @ds_iblock_levels: maximum number of levels for regular files
|
||||
* @ds_data_levels: number of seperate levels for data
|
||||
* @ds_data_levels: number of separate levels for data
|
||||
* @pad0: reserved, must be 0
|
||||
* @ds_feature_incompat: incompatible filesystem features
|
||||
* @ds_feature_ro_compat: read-only compatible filesystem features
|
||||
|
@ -456,7 +456,7 @@ enum logfs_vim {
|
|||
* @vim: life expectancy of data
|
||||
*
|
||||
* "Areas" are segments currently being used for writing. There is at least
|
||||
* one area per GC level. Several may be used to seperate long-living from
|
||||
* one area per GC level. Several may be used to separate long-living from
|
||||
* short-living data. If an area with unknown vim is encountered, it can
|
||||
* simply be closed.
|
||||
* The write buffer immediately follow this header.
|
||||
|
|
Loading…
Reference in a new issue