mirror of
https://github.com/apache/nuttx.git
synced 2026-06-04 23:03:27 +08:00
Remove exra whitespace from files (#189)
* Remove multiple newlines at the end of files * Remove the whitespace from the end of lines
This commit is contained in:
Xiang Xiao
Gregory Nutt
@@ -466,4 +466,3 @@ static int binfs_stat(struct inode *mountpt, const char *relpath, struct stat *b
|
||||
****************************************************************************/
|
||||
|
||||
#endif /* !CONFIG_DISABLE_MOUNTPOINT && CONFIG_FS_BINFS */
|
||||
|
||||
|
||||
@@ -39,4 +39,3 @@ CSRCS += fs_closedir.c fs_opendir.c fs_readdir.c fs_rewinddir.c fs_seekdir.c
|
||||
|
||||
DEPPATH += --dep-path dirent
|
||||
VPATH += :dirent
|
||||
|
||||
|
||||
@@ -363,4 +363,3 @@ errout_free:
|
||||
kmm_free(dev);
|
||||
return ret;
|
||||
}
|
||||
|
||||
|
||||
@@ -113,4 +113,3 @@ int register_mtdpartition(FAR const char *partition,
|
||||
|
||||
return OK;
|
||||
}
|
||||
|
||||
|
||||
@@ -208,4 +208,3 @@ out_with_blkdev:
|
||||
kmm_free(blkdev);
|
||||
return ret;
|
||||
}
|
||||
|
||||
|
||||
@@ -111,4 +111,3 @@ int register_blockdriver(FAR const char *path,
|
||||
}
|
||||
|
||||
#endif /* !CONFIG_DISABLE_MOUNTPOINT */
|
||||
|
||||
|
||||
@@ -111,4 +111,3 @@ int register_mtddriver(FAR const char *path, FAR struct mtd_dev_s *mtd,
|
||||
}
|
||||
|
||||
#endif /* CONFIG_MTD && !CONFIG_DISABLE_MOUNTPOINT */
|
||||
|
||||
|
||||
@@ -201,4 +201,3 @@ int fat_setattrib(const char *path, fat_attrib_t setbits, fat_attrib_t clearbits
|
||||
{
|
||||
return fat_attrib(path, NULL, setbits, clearbits);
|
||||
}
|
||||
|
||||
|
||||
@@ -42,4 +42,3 @@ CSRCS += fs_fileopen.c fs_filedetach.c fs_fileclose.c
|
||||
|
||||
DEPPATH += --dep-path inode
|
||||
VPATH += :inode
|
||||
|
||||
|
||||
@@ -152,4 +152,3 @@ int file_detach(int fd, FAR struct file *filep)
|
||||
_files_semgive(list);
|
||||
return OK;
|
||||
}
|
||||
|
||||
|
||||
@@ -226,4 +226,3 @@ int foreach_inode(foreach_inode_t handler, FAR void *arg)
|
||||
|
||||
#endif
|
||||
}
|
||||
|
||||
|
||||
@@ -92,4 +92,3 @@ void inode_release(FAR struct inode *node)
|
||||
}
|
||||
}
|
||||
}
|
||||
|
||||
|
||||
+18
-19
@@ -310,7 +310,7 @@ a directory entry?
|
||||
|
||||
One way to find the overhead per block is to look at the data structure as
|
||||
multiple layers of linked-lists. Each linked-list skips twice as many blocks
|
||||
as the previous linked-list. Another way of looking at it is that each
|
||||
as the previous linked-list. Another way of looking at it is that each
|
||||
linked-list uses half as much storage per block as the previous linked-list.
|
||||
As we approach infinity, the number of pointers per block forms a geometric
|
||||
series. Solving this geometric series gives us an average of only 2 pointers
|
||||
@@ -326,14 +326,14 @@ results in more pointers, and a larger word width results in larger pointers.
|
||||
|
||||
|
||||
|
||||
where:
|
||||
B = block size in bytes
|
||||
w = word width in bits
|
||||
where:
|
||||
B = block size in bytes
|
||||
w = word width in bits
|
||||
|
||||
Solving the equation for B gives us the minimum block size for various word
|
||||
widths:
|
||||
32 bit CTZ skip-list = minimum block size of 104 bytes
|
||||
64 bit CTZ skip-list = minimum block size of 448 bytes
|
||||
widths:
|
||||
32 bit CTZ skip-list = minimum block size of 104 bytes
|
||||
64 bit CTZ skip-list = minimum block size of 448 bytes
|
||||
|
||||
Since littlefs uses a 32 bit word size, we are limited to a minimum block
|
||||
size of 104 bytes. This is a perfectly reasonable minimum block size, with most
|
||||
@@ -356,11 +356,11 @@ file size. We can write this equation as a summation:
|
||||
|
||||
|
||||
|
||||
where:
|
||||
B = block size in bytes
|
||||
w = word width in bits
|
||||
n = block index in skip-list
|
||||
N = file size in bytes
|
||||
where:
|
||||
B = block size in bytes
|
||||
w = word width in bits
|
||||
n = block index in skip-list
|
||||
N = file size in bytes
|
||||
|
||||
And this works quite well, but is not trivial to calculate. This equation
|
||||
requires O(n) to compute, which brings the entire runtime of reading a file
|
||||
@@ -380,9 +380,9 @@ unintuitive property:
|
||||
|
||||
|
||||
|
||||
where:
|
||||
ctz(x) = the number of trailing bits that are 0 in x
|
||||
popcount(x) = the number of bits that are 1 in x
|
||||
where:
|
||||
ctz(x) = the number of trailing bits that are 0 in x
|
||||
popcount(x) = the number of bits that are 1 in x
|
||||
|
||||
It's a bit bewildering that these two seemingly unrelated bitwise instructions
|
||||
are related by this property. But if we start to dissect this equation we can
|
||||
@@ -516,9 +516,9 @@ However, this approach had several issues:
|
||||
|
||||
Actually, to simplify, this approach had one massive glaring issue: complexity.
|
||||
|
||||
> Complexity leads to fallibility.
|
||||
> Fallibility leads to unmaintainability.
|
||||
> Unmaintainability leads to suffering.
|
||||
> Complexity leads to fallibility.
|
||||
> Fallibility leads to unmaintainability.
|
||||
> Unmaintainability leads to suffering.
|
||||
|
||||
Or at least, complexity leads to increased code size, which is a problem
|
||||
for embedded systems.
|
||||
@@ -1223,4 +1223,3 @@ So, to summarize:
|
||||
by a deorphan step that occurs on the first allocation after boot
|
||||
|
||||
That's the little filesystem. Thanks for reading!
|
||||
|
||||
|
||||
@@ -6,4 +6,3 @@ config FS_LITTLEFS
|
||||
depends on !DISABLE_MOUNTPOINT
|
||||
---help---
|
||||
Build the LITTLEFS file system. https://github.com/ARMmbed/littlefs.
|
||||
|
||||
|
||||
@@ -1,8 +1,8 @@
|
||||
## usage
|
||||
## usage
|
||||
|
||||
depends on !DISABLE_MOUNTPOINT
|
||||
|
||||
1. register_mtddriver("/dev/w25", mtd, 0755, NULL);
|
||||
1. register_mtddriver("/dev/w25", mtd, 0755, NULL);
|
||||
2. mount("/dev/w25", "/w25", "littlefs", 0, NULL);
|
||||
|
||||
## need to do
|
||||
|
||||
@@ -44,4 +44,3 @@ endif
|
||||
|
||||
DEPPATH += --dep-path mmap
|
||||
VPATH += :mmap
|
||||
|
||||
|
||||
@@ -55,4 +55,3 @@ DEPPATH += --dep-path mount
|
||||
VPATH += :mount
|
||||
|
||||
endif
|
||||
|
||||
|
||||
@@ -541,4 +541,3 @@ errout:
|
||||
}
|
||||
|
||||
#endif /* CONFIG_FS_READABLE */
|
||||
|
||||
|
||||
@@ -103,4 +103,3 @@ FAR const char *fs_gettype(FAR struct statfs *statbuf);
|
||||
|
||||
#endif /* CONFIG_DISABLE_MOUNTPOINT */
|
||||
#endif /* __FS_MOUNT_MOUNT_H */
|
||||
|
||||
|
||||
@@ -93,4 +93,3 @@ void mq_inode_release(FAR struct inode *inode);
|
||||
#endif
|
||||
|
||||
#endif /* __FS_MQUEUE_MQUEUE_H */
|
||||
|
||||
|
||||
@@ -571,4 +571,3 @@ struct FS3args
|
||||
};
|
||||
|
||||
#endif /* __FS_NFS_NFS_PROTO_H */
|
||||
|
||||
|
||||
@@ -189,4 +189,3 @@ Things to Do
|
||||
implementation of a proper truncate() method which should alter the
|
||||
size of a previously written file. There is some fragmentary logic in
|
||||
place but even this is conditioned out with __NO_TRUNCATE_SUPPORT__.
|
||||
|
||||
|
||||
@@ -1136,5 +1136,3 @@ int nxffs_stat(FAR struct inode *mountpt, FAR const char *relpath,
|
||||
int nxffs_unlink(FAR struct inode *mountpt, FAR const char *relpath);
|
||||
|
||||
#endif /* __FS_NXFFS_NXFFS_H */
|
||||
|
||||
|
||||
|
||||
@@ -167,4 +167,3 @@ out:
|
||||
kmm_free(ptable);
|
||||
return ret;
|
||||
}
|
||||
|
||||
|
||||
@@ -320,4 +320,3 @@ static int version_stat(FAR const char *relpath, FAR struct stat *buf)
|
||||
|
||||
#endif /* CONFIG_FS_PROCFS_EXCLUDE_PROCESS */
|
||||
#endif /* !CONFIG_DISABLE_MOUNTPOINT && CONFIG_FS_PROCFS */
|
||||
|
||||
|
||||
@@ -130,4 +130,3 @@ int sem_close(FAR sem_t *sem)
|
||||
}
|
||||
|
||||
#endif /* CONFIG_FS_NAMED_SEMAPHORES */
|
||||
|
||||
|
||||
@@ -70,4 +70,3 @@ extern "C"
|
||||
#endif
|
||||
|
||||
#endif /* __FS_SEMAPHORE_SEMAPHORE_H */
|
||||
|
||||
|
||||
+1
-1
@@ -25,7 +25,7 @@ config SMARTFS_ERASEDSTATE
|
||||
config SMARTFS_MAXNAMLEN
|
||||
int "Maximum file name length"
|
||||
default 16
|
||||
---help---
|
||||
---help---
|
||||
The maximum size of a SMARTFS file name at a given
|
||||
directory level. Overall path name is not restricted
|
||||
by this value, only individual segments in a path,
|
||||
|
||||
+15
-15
@@ -1,4 +1,4 @@
|
||||
# SPIFFS (SPI Flash File System)
|
||||
# SPIFFS (SPI Flash File System)
|
||||
**V0.3.7**
|
||||
|
||||
[](https://travis-ci.org/pellepl/spiffs)
|
||||
@@ -38,12 +38,12 @@ What spiffs does:
|
||||
- Posix-like api: open, close, read, write, seek, stat, etc
|
||||
- It can run on any NOR flash, not only SPI flash - theoretically also on embedded flash of a microprocessor
|
||||
- Multiple spiffs configurations can run on same target - and even on same SPI flash device
|
||||
- Implements static wear leveling
|
||||
- Implements static wear leveling
|
||||
- Built in file system consistency checks
|
||||
- Highly configurable
|
||||
|
||||
|
||||
What spiffs does not:
|
||||
- Presently, spiffs does not support directories. It produces a flat structure. Creating a file with path *tmp/myfile.txt* will create a file called *tmp/myfile.txt* instead of a *myfile.txt* under directory *tmp*.
|
||||
- Presently, spiffs does not support directories. It produces a flat structure. Creating a file with path *tmp/myfile.txt* will create a file called *tmp/myfile.txt* instead of a *myfile.txt* under directory *tmp*.
|
||||
- It is not a realtime stack. One write operation might last much longer than another.
|
||||
- Poor scalability. Spiffs is intended for small memory devices - the normal sizes for SPI flashes. Going beyond ~128Mbyte is probably a bad idea. This is a side effect of the design goal to use as little ram as possible.
|
||||
- Presently, it does not detect or handle bad blocks.
|
||||
@@ -52,11 +52,11 @@ What spiffs does not:
|
||||
## NOTICE
|
||||
|
||||
0.4.0 is under construction. This is a full rewrite and will change the underlying structure. Hence, it will not be compatible with earlier versions of the filesystem. The API is the same, with minor modifications. Some config flags will be removed (as they are mandatory in 0.4.0) and some features might fall away until 0.4.1. If you have any worries or questions, it can be discussed in issue [#179](https://github.com/pellepl/spiffs/issues/179)
|
||||
|
||||
## MORE INFO
|
||||
|
||||
|
||||
## MORE INFO
|
||||
|
||||
See the [wiki](https://github.com/pellepl/spiffs/wiki) for [configuring](https://github.com/pellepl/spiffs/wiki/Configure-spiffs), [integrating](https://github.com/pellepl/spiffs/wiki/Integrate-spiffs), [using](https://github.com/pellepl/spiffs/wiki/Using-spiffs), and [optimizing](https://github.com/pellepl/spiffs/wiki/Performance-and-Optimizing) spiffs.
|
||||
|
||||
|
||||
For design, see [docs/TECH_SPEC](https://github.com/pellepl/spiffs/blob/master/docs/TECH_SPEC).
|
||||
|
||||
For a generic spi flash driver, see [this](https://github.com/pellepl/spiflash_driver).
|
||||
@@ -69,7 +69,7 @@ For a generic spi flash driver, see [this](https://github.com/pellepl/spiflash_d
|
||||
- fixed cache page not closed for removed files #156
|
||||
- fixed a lseek bug when seeking exactly to end of a fully indexed first level LUT #148
|
||||
- fixed wear leveling issue #145
|
||||
- fixed attempt to write out of bounds in flash #130,
|
||||
- fixed attempt to write out of bounds in flash #130,
|
||||
- set file offset when seeking over end #121 (thanks @sensslen)
|
||||
- fixed seeking in virgin files #120 (thanks @sensslen)
|
||||
- Optional file metadata #128 (thanks @cesanta)
|
||||
@@ -101,9 +101,9 @@ New API functions:
|
||||
- `SPIFFS_ix_remap` - changes file offset for index metadata map
|
||||
- `SPIFFS_bytes_to_ix_map_entries` - utility, get length of needed vector for given amount of bytes
|
||||
- `SPIFFS_ix_map_entries_to_bytes` - utility, get number of bytes a vector can represent given length
|
||||
|
||||
|
||||
New config defines:
|
||||
- `SPIFFS_IX_MAP` - enable possibility to map index meta data to memory for reading faster
|
||||
- `SPIFFS_IX_MAP` - enable possibility to map index meta data to memory for reading faster
|
||||
- `SPIFFS_TEMPORAL_FD_CACHE` - enable temporal cache for opening files faster
|
||||
- `SPIFFS_TEMPORAL_CACHE_HIT_SCORE` - for tuning the temporal cache
|
||||
|
||||
@@ -116,7 +116,7 @@ New config defines:
|
||||
- Problem with long filenames #79 (thanks @psjg)
|
||||
- Duplicate file name bug fix #74 (thanks @igrr)
|
||||
- SPIFFS_eof and SPIFFS_tell return wrong value #72 (thanks @ArtemPisarenko)
|
||||
- Bunch of testframe updates #77 #78 #86 (thanks @dpreussner, @psjg a.o)
|
||||
- Bunch of testframe updates #77 #78 #86 (thanks @dpreussner, @psjg a.o)
|
||||
|
||||
### 0.3.4
|
||||
- Added user callback file func.
|
||||
@@ -155,8 +155,8 @@ New config defines:
|
||||
- Moar comments for SPIFFS_lseek (thanks @igrr)
|
||||
- Fixed padding in spiffs_page_object_ix #40 (thanks @jmattsson @lishen2)
|
||||
- Fixed gc_quick test (thanks @jmattsson)
|
||||
- Add SPIFFS_EXCL flag #36
|
||||
- SPIFFS_close may fail silently if cache is enabled #37
|
||||
- Add SPIFFS_EXCL flag #36
|
||||
- SPIFFS_close may fail silently if cache is enabled #37
|
||||
- User data in callbacks #34
|
||||
- Ignoring SINGLETON build in cache setup (thanks Luca)
|
||||
- Compilation error fixed #32 (thanks @chotasanjiv)
|
||||
@@ -182,7 +182,7 @@ New config defines:
|
||||
- Test sigsevs when having too many sectors #13 (thanks alonewolfx2)
|
||||
- GC might be suboptimal #11
|
||||
- Fix eternal readdir when objheader at last block, last entry
|
||||
|
||||
|
||||
New API functions:
|
||||
- `SPIFFS_gc_quick` - call a nonintrusive gc
|
||||
- `SPIFFS_gc` - call a full-scale intrusive gc
|
||||
|
||||
+39
-40
@@ -10,7 +10,7 @@ for bigger targets with much more ram. Nevertheless, many wise thoughts have
|
||||
been borrowed from YAFFS when writing spiffs. Kudos!
|
||||
|
||||
The main complication writing spiffs was that it cannot be assumed the target
|
||||
has a heap. Spiffs must go along only with the work ram buffer given to it.
|
||||
has a heap. Spiffs must go along only with the work ram buffer given to it.
|
||||
This forces extra implementation on many areas of spiffs.
|
||||
|
||||
|
||||
@@ -20,15 +20,15 @@ Below is a small description of how SPI flashes work internally. This is to
|
||||
give an understanding of the design choices made in spiffs.
|
||||
|
||||
SPI flash devices are physically divided in blocks. On some SPI flash devices,
|
||||
blocks are further divided into sectors. Datasheets sometimes name blocks as
|
||||
blocks are further divided into sectors. Datasheets sometimes name blocks as
|
||||
sectors and vice versa.
|
||||
|
||||
Common memory capacaties for SPI flashes are 512kB up to 8MB of data, where
|
||||
blocks may be 64kB. Sectors can be e.g. 4kB, if supported. Many SPI flashes
|
||||
have uniform block sizes, whereas others have non-uniform - the latter meaning
|
||||
blocks may be 64kB. Sectors can be e.g. 4kB, if supported. Many SPI flashes
|
||||
have uniform block sizes, whereas others have non-uniform - the latter meaning
|
||||
that e.g. the first 16 blocks are 4kB big, and the rest are 64kB.
|
||||
|
||||
The entire memory is linear and can be read and written in random access.
|
||||
The entire memory is linear and can be read and written in random access.
|
||||
Erasing can only be done block- or sectorwise; or by mass erase.
|
||||
|
||||
SPI flashes can normally be erased from 100.000 up to 1.000.000 cycles before
|
||||
@@ -37,7 +37,7 @@ they fail.
|
||||
A clean SPI flash from factory have all bits in entire memory set to one. A
|
||||
mass erase will reset the device to this state. Block or sector erasing will
|
||||
put the all bits in the area given by the sector or block to ones. Writing to a
|
||||
NOR flash pulls ones to zeroes. Writing 0xFF to an address is simply a no-op.
|
||||
NOR flash pulls ones to zeroes. Writing 0xFF to an address is simply a no-op.
|
||||
|
||||
Writing 0b10101010 to a flash address holding 0b00001111 will yield 0b00001010.
|
||||
|
||||
@@ -45,7 +45,7 @@ This way of "write by nand" is used considerably in spiffs.
|
||||
|
||||
Common characteristics of NOR flashes are quick reads, but slow writes.
|
||||
|
||||
And finally, unlike NAND flashes, NOR flashes seem to not need any error
|
||||
And finally, unlike NAND flashes, NOR flashes seem to not need any error
|
||||
correction. They always write correctly I gather.
|
||||
|
||||
|
||||
@@ -57,9 +57,9 @@ in the datasheet. Logical blocks and pages is something the integrator choose.
|
||||
|
||||
** Blocks and pages
|
||||
|
||||
Spiffs is allocated to a part or all of the memory of the SPI flash device.
|
||||
This area is divided into logical blocks, which in turn are divided into
|
||||
logical pages. The boundary of a logical block must coincide with one or more
|
||||
Spiffs is allocated to a part or all of the memory of the SPI flash device.
|
||||
This area is divided into logical blocks, which in turn are divided into
|
||||
logical pages. The boundary of a logical block must coincide with one or more
|
||||
physical blocks. The sizes for logical blocks and logical pages always remain
|
||||
the same, they are uniform.
|
||||
|
||||
@@ -88,7 +88,7 @@ PHYSICAL FLASH BLOCKS SPIFFS LOGICAL BLOCKS: 128kB
|
||||
+-----------------------+ - - - +-----------------------+
|
||||
| ... | | ... |
|
||||
|
||||
A logical block is divided further into a number of logical pages. A page
|
||||
A logical block is divided further into a number of logical pages. A page
|
||||
defines the smallest data holding element known to spiffs. Hence, if a file
|
||||
is created being one byte big, it will occupy one page for index and one page
|
||||
for data - it will occupy 2 x size of a logical page on flash.
|
||||
@@ -100,7 +100,7 @@ page size of 64 bytes will waste 8-14% on metadata, while 256 bytes 2-4%.
|
||||
So it seems it is good to select a big page size.
|
||||
|
||||
Also, spiffs uses a ram buffer being two times the page size. This ram buffer
|
||||
is used for loading and manipulating pages, but it is also used for algorithms
|
||||
is used for loading and manipulating pages, but it is also used for algorithms
|
||||
to find free file ids, scanning the file system, etc. Having too small a page
|
||||
size means less work buffer for spiffs, ending up in more reads operations and
|
||||
eventually gives a slower file system.
|
||||
@@ -112,21 +112,21 @@ Choosing the page size for the system involves many factors:
|
||||
- How much data (vs metadata) must be crammed into the file system
|
||||
- How fast must spiffs be
|
||||
- Other things impossible to find out
|
||||
|
||||
So, chosing the Optimal Page Size (tm) seems tricky, to say the least. Don't
|
||||
|
||||
So, chosing the Optimal Page Size (tm) seems tricky, to say the least. Don't
|
||||
fret - there is no optimal page size. This varies from how the target will use
|
||||
spiffs. Use the golden rule:
|
||||
|
||||
~~~ Logical Page Size = Logical Block Size / 256 ~~~
|
||||
|
||||
This is a good starting point. The final page size can then be derived through
|
||||
This is a good starting point. The final page size can then be derived through
|
||||
heuristical experimenting for us non-analytical minds.
|
||||
|
||||
|
||||
** Objects, indices and look-ups
|
||||
|
||||
A file, or an object as called in spiffs, is identified by an object id.
|
||||
Another YAFFS rip-off. This object id is a part of the page header. So, all
|
||||
A file, or an object as called in spiffs, is identified by an object id.
|
||||
Another YAFFS rip-off. This object id is a part of the page header. So, all
|
||||
pages know to which object/file they belong - not counting the free pages.
|
||||
|
||||
An object is made up of two types of pages: object index pages and data pages.
|
||||
@@ -134,19 +134,19 @@ Data pages contain the data written by user. Index pages contain metadata about
|
||||
the object, more specifically what data pages are part of the object.
|
||||
|
||||
The page header also includes something called a span index. Let's say a file
|
||||
is written covering three data pages. The first data page will then have span
|
||||
is written covering three data pages. The first data page will then have span
|
||||
index 0, the second span index 1, and the last data page will have span index
|
||||
2. Simple as that.
|
||||
2. Simple as that.
|
||||
|
||||
Finally, each page header contain flags, telling if the page is used,
|
||||
Finally, each page header contain flags, telling if the page is used,
|
||||
deleted, finalized, holds index or data, and more.
|
||||
|
||||
Object indices also have span indices, where an object index with span index 0
|
||||
is referred to as the object index header. This page does not only contain
|
||||
is referred to as the object index header. This page does not only contain
|
||||
references to data pages, but also extra info such as object name, object size
|
||||
in bytes, flags for file or directory, etc.
|
||||
|
||||
If one were to create a file covering three data pages, named e.g.
|
||||
If one were to create a file covering three data pages, named e.g.
|
||||
"spandex-joke.txt", given object id 12, it could look like this:
|
||||
|
||||
PAGE 0 <things to be unveiled soon>
|
||||
@@ -164,9 +164,9 @@ PAGE 4 page header: [obj_id:12 span_ix:2 flags:USED|DATA]
|
||||
<third data page of joke>
|
||||
|
||||
PAGE 5 page header: [obj_id:12 span_ix:0 flags:USED|INDEX]
|
||||
obj ix header: [name:spandex-joke.txt size:600 bytes flags:FILE]
|
||||
obj ix header: [name:spandex-joke.txt size:600 bytes flags:FILE]
|
||||
obj ix: [1 2 4]
|
||||
|
||||
|
||||
Looking in detail at page 5, the object index header page, the object index
|
||||
array refers to each data page in order, as mentioned before. The index of the
|
||||
object index array correlates with the data page span index.
|
||||
@@ -177,25 +177,25 @@ object index array correlates with the data page span index.
|
||||
PAGE 1, DATA, SPAN_IX 0 --------/ | |
|
||||
PAGE 2, DATA, SPAN_IX 1 --------/ |
|
||||
PAGE 4, DATA, SPAN_IX 2 --------/
|
||||
|
||||
Things to be unveiled in page 0 - well.. Spiffs is designed for systems low on
|
||||
ram. We cannot keep a dynamic list on the whereabouts of each object index
|
||||
header so we can find a file fast. There might not even be a heap! But, we do
|
||||
|
||||
Things to be unveiled in page 0 - well.. Spiffs is designed for systems low on
|
||||
ram. We cannot keep a dynamic list on the whereabouts of each object index
|
||||
header so we can find a file fast. There might not even be a heap! But, we do
|
||||
not want to scan all page headers on the flash to find the object index header.
|
||||
|
||||
The first page(s) of each block contains the so called object look-up. These
|
||||
are not normal pages, they do not have a header. Instead, they are arrays
|
||||
The first page(s) of each block contains the so called object look-up. These
|
||||
are not normal pages, they do not have a header. Instead, they are arrays
|
||||
pointing out what object-id the rest of all pages in the block belongs to.
|
||||
|
||||
By this look-up, only the first page(s) in each block must to scanned to find
|
||||
By this look-up, only the first page(s) in each block must to scanned to find
|
||||
the actual page which contains the object index header of the desired object.
|
||||
|
||||
The object lookup is redundant metadata. The assumption is that it presents
|
||||
The object lookup is redundant metadata. The assumption is that it presents
|
||||
less overhead reading a full page of data to memory from each block and search
|
||||
that, instead of reading a small amount of data from each page (i.e. the page
|
||||
header) in all blocks. Each read operation from SPI flash normally contains
|
||||
that, instead of reading a small amount of data from each page (i.e. the page
|
||||
header) in all blocks. Each read operation from SPI flash normally contains
|
||||
extra data as the read command itself and the flash address. Also, depending on
|
||||
the underlying implementation, other criterions may need to be passed for each
|
||||
the underlying implementation, other criterions may need to be passed for each
|
||||
read transaction, like mutexes and such.
|
||||
|
||||
The veiled example unveiled would look like this, with some extra pages:
|
||||
@@ -221,12 +221,12 @@ up. This is an example where spiffs uses NOR flashes "nand-way" of writing.
|
||||
|
||||
As a matter of fact, there are two object id's which are special:
|
||||
|
||||
obj id 0 (all bits zeroes) - indicates a deleted page in object look up
|
||||
obj id 0xff.. (all bits ones) - indicates a free page in object look up
|
||||
obj id 0 (all bits zeroes) - indicates a deleted page in object look up
|
||||
obj id 0xff.. (all bits ones) - indicates a free page in object look up
|
||||
|
||||
Actually, the object id's have another quirk: if the most significant bit is
|
||||
set, this indicates an object index page. If the most significant bit is zero,
|
||||
this indicates a data page. So to be fully correct, page 0 in above example
|
||||
this indicates a data page. So to be fully correct, page 0 in above example
|
||||
would look like this:
|
||||
|
||||
PAGE 0 [ 12 12 545 12 *12 34 34 *4 0 0 0 0 ...]
|
||||
@@ -234,6 +234,5 @@ PAGE 0 [ 12 12 545 12 *12 34 34 *4 0 0 0 0 ...]
|
||||
where the asterisk means the msb of the object id is set.
|
||||
|
||||
This is another way to speed up the searches when looking for object indices.
|
||||
By looking on the object id's msb in the object lookup, it is also possible
|
||||
By looking on the object id's msb in the object lookup, it is also possible
|
||||
to find out whether the page is an object index page or a data page.
|
||||
|
||||
|
||||
@@ -25,4 +25,3 @@ config FS_UNIONFS
|
||||
by the file in file system1.
|
||||
|
||||
See include/nutts/unionfs.h for additional information.
|
||||
|
||||
|
||||
@@ -112,4 +112,3 @@ int dup2(int fd1, int fd2)
|
||||
}
|
||||
|
||||
#endif /* CONFIG_NET */
|
||||
|
||||
|
||||
@@ -145,4 +145,3 @@ errout:
|
||||
set_errno(-ret);
|
||||
return ERROR;
|
||||
}
|
||||
|
||||
|
||||
@@ -232,4 +232,3 @@ int epoll_wait(int epfd, FAR struct epoll_event *evs, int maxevents,
|
||||
|
||||
return i;
|
||||
}
|
||||
|
||||
|
||||
@@ -191,4 +191,3 @@ errout:
|
||||
set_errno(errcode);
|
||||
return (off_t)ERROR;
|
||||
}
|
||||
|
||||
|
||||
@@ -536,4 +536,3 @@ int poll(FAR struct pollfd *fds, nfds_t nfds, int timeout)
|
||||
|
||||
return count;
|
||||
}
|
||||
|
||||
|
||||
@@ -284,4 +284,3 @@ errout:
|
||||
leave_cancellation_point();
|
||||
return ERROR;
|
||||
}
|
||||
|
||||
|
||||
@@ -149,4 +149,3 @@ ssize_t sendfile(int outfd, int infd, off_t *offset, size_t count)
|
||||
}
|
||||
|
||||
#endif /* CONFIG_NET_SENDFILE */
|
||||
|
||||
|
||||
Reference in New Issue
Block a user