Wiley.Symbian.OS.Internals.Real.time.Kernel.Programming.Dec.2005.eBook-DDU (779891), страница 79
Текст из файла (страница 79)
This is because it cannot reclaimany segment that contains FDBs whose metadata it has not rolled forward,because this reclaim could destroy information needed to reconstruct themetadata.9.4.2.7 CachingThe LFFS maintains a cache which holds both read data and pendingwrite data. This cache includes all types of data – not only FDBs, but alsometadata and log entries. The cache tracks the pending write data foreach file separately, and can therefore act on cached data from only onefile.
For example, data for a single file can be flushed without having toflush data for any other file. If you are building the LFFS for a new phoneplatform, you can configure the size of this cache by changing a constantin one of the LFFS configuration header files.There is also a separate read-ahead cache that reads log entries ingroups, for efficiency.9.4.2.8 Error recoveryIf, during a reclaim, the LFFS detects an erase failure on a block, then itmarks the entire segment that contains that block as being bad (and nolonger available for use).
Again, it stores this information in the segmentheader. The LFFS then identifies another segment for reclaim, leaving theclient unaware of the error.If the LFFS detects a write failure on the current segment, then itreattempts the same write in the next available position on the samesegment. It repeats this, moving further through the segment until theFILE SYSTEMS375write eventually succeeds.
This may require the LFFS to move on to thenext free segment. Again, the client is unaware of any error. If it hassuffered a write error, it is likely that the damaged sector will also sufferan erase error if it is ever reclaimed, which will cause it to be marked asbad at that point.
However, assuming the damaged sector is still capableof being read, any valid data it contains will be moved to another segmentas part of the normal reclaim process.By configuring one of the LFFS configuration header files, developerswho are creating a new phone platform can build the LFFS so that it keepssegments in reserve to replace bad segments, so that drive capacity isn’treduced in erase failure situations.9.4.3 The FAT file systemSymbian OS uses the VFAT file system for user-data storage on variousmedia types including removable media, internal RAM and NAND Flash.On a FAT-formatted volume, the data area is divided into clusters, witha cluster being the smallest unit of data storage that can be allocated toa file. On a given volume, each cluster is the same size and is always awhole number of sectors (see Section 9.1.1.3).
Cluster size varies betweenvolumes, and depends on the size of the volume.A File Allocation Table (FAT) structure is used to track how clustersare allocated to each file. Since the original version of the FAT file systembecame available, it has been enhanced to support larger volumes. Nowthere are different FAT file system types, corresponding to differences inthe size of the entries used in the FAT data structure. These include FAT12for 12-bit entries, FAT16 for 16-bit entries and FAT32 for 32-bit entries.Directory information is stored in a directory table, in which each tableentry is a 32-byte data structure. The VFAT version of the standard supportslong file names, up to 255 characters in length – previous versionssupported only ‘‘8.3’’ filenames that can only have eight characters, aperiod, and a three-character extension. The FAT and VFAT standards aredescribed in many publications and I will not describe them in any moredetail here.To ensure that Symbian OS phones are compatible with other operatingsystems, it was essential that we used the FAT file system on our removablemedia.
Data on a removable media card that has been formatted andupdated on a Symbian OS phone must be fully accessible when removedand introduced into other computer systems, such as a card readerconnected to a PC – and vice versa. In some cases, compatibility withother systems can also mandate that internal drives be FAT formatted.This is because some Symbian OS phones support remote access froma host machine (such as a desktop computer) to one or more of theirinternal drives, by exposing these as USB mass storage devices. For this towork without a special driver on the host machine, these internal drivesmust be FAT-format.376THE FILE SERVERSymbian OS always formats internal RAM drives using FAT16.Symbian OS actually provides two builds of the FAT file system – onethat supports only FAT12 and FAT16, and a second that supports FAT32as well.
This is because not all Symbian OS licensees require support forFAT32.9.4.3.1 Rugged FAT versionWe build both FAT12/16 and FAT32 in a rugged configuration bydefault – although developers who are creating a new phone platformcan enable the standard version if they wish. The rugged FAT versionprovides tolerance to situations in which write operations are interrupteddue to power failure. This only happens when there is an unexpected lossof battery power, not from the user’s normal power down of the phone,because in this case the file server can complete the operation beforeturning off.The rugged version alters the way in which the file system updates theFAT tables and directory entries, but this alone can’t completely eliminatethe possibility of an error due to unexpected power removal.
However,it also incorporates a ScanDrive utility, which the file server runs whenpower is restored to the disk – and this can fix up any such errors. Forexample, ScanDrive can detect and correct inconsistencies between theFAT table and the directory entries, to reclaim lost clusters. It does this bygenerating its own version of the FAT table from analyzing the directoryentries and then comparing this with the current FAT table. ScanDrive runsat system boot, but only if the phone has been unexpectedly powereddown. In normal power down situations, the Symbian OS shutdownserver (SHUTDOWNSRVS.EXE) sends notification to the file server oforderly shutdown, using the F32 method RFs::FinaliseDrives().The file server passes notification down to the FAT file system, and this isthen able to update a status flag on the FAT disk. When it starts up, thefile system checks the status flag, allowing it to only run ScanDrive whenit is needed.However this power-safe, rugged scheme only applies if the underlyinglocal media sub-system can guarantee atomic sector writes – that is, asector involved in a write operation is never left in a partially modifiedstate due to power removal, but is either updated completely, or leftunmodified.
We can provide this guarantee for internal FAT drives thatuse a translation layer over NAND Flash.For removable media devices, unexpected power removal may resultfrom the removal of the card from the phone, as well as from the lossof power from the battery. For these devices, we can’t usually guaranteeatomic sector writes. However, we can minimize the possibility of cardcorruption due to unexpected power removal, using schemes such asnot allowing writes when the battery voltage is low. Another way ofFILE SYSTEMS377minimizing corruption is the use of a card door scheme that providesearly warning of the possibility of card removal.
Unfortunately theseschemes can’t catch everything – consider the situation where the phoneis accidentally dropped, resulting in the battery being released during awrite operation. We could protect against corruption in this scenario withthe use of a backup battery that preserves system RAM while the mainbattery is missing, so that we can retry the original write operation whenthe main supply is restored.
Unfortunately, the use of a backup battery isnot popular with phone manufacturers, due to the increase in the bill ofmaterials for the phone.9.4.3.2 CachingWhen we use the FAT file system on either removable media or NANDFlash drives, we always employ two caching schemes to improve performance.The first of these is a cache for the FAT itself. The file system caches theentire FAT into RAM, for all drives formatted using FAT12 or FAT16, andfor any drives formatted using FAT32 whose FAT is smaller than 128 KB.This is a ‘‘write-back with dirty bit’’ type of cache scheme, with the filesystem flushing all dirty segments at certain critical points throughouteach file server operation.
This cache is used so that short sequencesof updates to the FAT can be accumulated and written in one go. Thefrequency of cache flushes is higher, for a given operation, if the filesystem is configured for rugged operation. The segment size within thiscache is 512 bytes. This corresponds to the smallest unit of access for thesector-based media that the cache is used for.However, for larger drives formatted with FAT32, the size of the FATbecomes too large for it to be entirely cached into RAM. Instead, onlypart of the table is cached. The cache stores up to 256 segments andemploys an LRU (Least Recently Used) scheme when it needs to replacea segment.
Each segment is still 512 bytes long.The other type of cache, which we use on NAND Flash and removablemedia drives, is a metadata cache. This caches the most recently accesseddirectory entries together with the initial sectors of files. Caching the firstpart of a file improves the speed of the file server when it is handling clientrequests to read file UIDs. Each cache segment is again 512 bytes and thefile system is built allowing a maximum cache size of 64 segments.
![](https://s.studizba.com/z.php?f=/templates/si/i/noavatar.png&w=100&h=100&t=1"){kind=avatar}
