Wiley.Symbian.OS.Internals.Real.time.Kernel.Programming.Dec.2005.eBook-DDU (779891), страница 80
Текст из файла (страница 80)
Oncemore, we use an LRU replacement scheme. However, this is a ‘‘writethrough’’ type cache – it always reflects the contents of the drive.9.4.3.3 User-data storage on NAND FlashNAND Flash characteristicsIn Section 9.4.2.1, I described the characteristics of NOR Flash. NANDFlash is similar. It is nonvolatile memory that can be erased and rewritten.378THE FILE SERVERWrite operations change bits from one to zero, but an entire block mustbe erased to change a bit from a zero to a one. Again, there is a limit tothe number of times a block of NAND Flash can be erased and rewritten.However, there are a number of differences between the characteristicsof NAND and NOR Flash:• Unlike NOR Flash, NAND Flash devices are not byte-addressable –they can only be read and written in page-sized units.
(These pagesare 512 bytes or larger, but are always smaller than the erase blocksize)• The geometry and timing characteristics of NAND and NOR Flashare different. NAND devices tend to have smaller blocks than NORdevices. Program and erase operations are faster on NAND Flash• NAND Flash has a low limit on the possible number of partial programcycles to the same page. (After being erased, all bits are in the ‘‘one’’state. Writing to a page moves some of the bits to a ‘‘zero’’ state. Theremaining bits at ‘‘one’’ can still be changed to zero without an erase,using a subsequent write operation to the same page.
This is called apartial program cycle.)As I mentioned at the start of Section 9.4.2, we designed the LFFSspecifically to enable user-data storage on NOR Flash. The differencesin the NAND Flash characteristics that I have listed mean that LFFS isnot a suitable file system for user-data storage on NAND Flash. The mostfundamental issue is the low limit on the number of partial page programcycles that are possible on NAND Flash.
As we saw, LFFS relies on beingable to perform partial programs to update the completion status of eachlog entry.The Flash translation layer (FTL)Instead, Symbian OS uses the FAT file system for user-data storage onNAND Flash. FAT is a file system better suited to the page read/write unitsize of NAND.However, because NAND pages have to be erased prior to a write,and because erase blocks contain multiple pages, we need an additionaltranslation layer for NAND, to provide the sector read/write interface thatFAT requires.
This is the NAND Flash translation layer (FTL).The translation layer also handles another characteristic of NANDFlash. When NAND devices are manufactured, they often contain a number of faulty blocks distributed throughout the device. Before the NANDdevice is shipped, its manufacturer writes information that identifies thebad blocks into a spare region of the NAND device. That is not all – asthe FTL writes to good blocks on the device, there is a chance that thesewill fail to erase or program, and become bad.
The likelihood of thisFILE SYSTEMS379occurring increases the more a block is erased. To handle these issues,the translation layer implements a Bad Block Manager (BBM), whichinterprets the bad block information from the manufacturer and updatesit with information about any new bad blocks that it detects. The BBMalso controls a reservoir of spare good blocks, and it uses these to replacebad ones encountered within the rest of the device.The translation layer handles wear leveling, employing a scheme verysimilar to that used by LFFS. It also provides a system for ensuring theintegrity of the data in situations of unexpected power removal, makingsure that data already successfully committed to the device is not lostin such a situation – even if power removal occurs part-way through awrite or erase operation.
Indeed, the FTL is so robust that it can handlethe situation in which power removal occurs while it is in the process ofrecovering from an earlier, unexpected, power removal.The NAND FTL implementation may be split between a user-sidefile server extension (see Section 9.1.2) and a media driver. It canalso be implemented wholly kernel-side in a media driver. The second scheme tends to result in a smaller number of executive callsbetween user-side code and the media driver which makes it slightlymore efficient.The first NAND FTL version released by Symbian employed a schemesplit between a file server extension and a media driver. We had to splitit this way on EKA1, and so we chose the same scheme for EKA2 toprovide compatibility between the two versions of the kernel.
We laterimplemented a version of the FTL for EKA2 entirely within a NAND mediadriver. Whichever scheme is used, the FTL and BBM software is generic toany NAND Flash device. However, the media driver contains a hardwareinterface layer, which is specific to the particular NAND device in use.Figure 9.16 shows the components required to support user-data storage on NAND Flash memory.File delete notificationThe FTL operates more efficiently as the amount of free space on the driveincreases, since it can make use of the unallocated space in its sectorre-mapping process. When a file is truncated or deleted on a FAT device,any clusters previously allocated to the file that become free are marked asavailable for reuse within the FAT. Normally, the contents of the clustersthemselves are left unaltered until they are reallocated to another file.But in this case, the underlying FTL can’t benefit from the additional freespace – it is not aware that the sectors associated with these clusters arenow free.
So, when the FAT file system is required to free up clusters – forexample, in the call CFatMountCB::DeleteL() – it calls down to thenext layer using the method:CProxyDrive::DeleteNotify(TInt64 aPos, TInt aLength)380THE FILE SERVERThis provides notification that the area specified within the argumentsis now free. If this layer is a file server extension implementing the FTL,then it can now make use of this information. If no extension is present,then the call can be passed down to the TBusLocalDrive interface,and on to the media driver where again an FTL can make use of theinformation.9.4.3.4 Removable media systemsThose Symbian OS phones that support removable media devices mustprovide a hardware scheme for detecting disk insertion or removal, andit is the local media sub-system that interfaces with this.
The file serverneeds to receive notification of these media change events so that itcan handle the possible change of volume, and also so it can pass theinformation on to any of its clients that have registered for disk eventnotification.I have already described (in Section 9.3.3.1) how the file server receivesnotification of a possible change of volume by registering a data memberof the appropriate TDrive class with the local media sub-system.I also mentioned (in Section 9.3.4) that a client might register fornotification of disk events, such as the insertion of a new volume.
Insteadof using this same TDrive mechanism to handle client notifiers, thefile server uses a slightly different scheme. It creates an instance of theCNotifyMediaChange class for each removable media socket. This isan active object that requests notification of media change events, againvia the local media sub-system. Each time a request is completed, theactive object handles any pending client notifiers and then reissues arequest on the local media sub-system for the next media change event.Media change events are involved in a third notification scheme. Forcertain critical media access failures, the file server sometimes needsto display a dialogue box on the screen prompting the user to takesome action to avoid disk corruption. This dialogue box is launched byan F32 critical notifier.
It is used by the FAT file system in situationswhere a read or write failure has occurred that could result in corruptionof the metadata on a volume. These situations include updates to theFAT tables and directory entries, and also running the ScanDrive utility.The dialogue box is only displayed on particular read/write errors. Forremovable media, these include errors caused by card power-down as aresult of a media change event – in this case, the dialogue box promptsthe user to replace the disk immediately to avoid disk corruption.We implement the critical notifier in the class CAsyncNotifier.Each drive can own an instance of this class, and any file system canuse it to provide a notifier service.
That said, currently only the FAT filesystem uses it.FILE SYSTEMS381CAsyncNotifier uses the RNotifier user library class, whichencapsulates a session with the extended notifier server – part of the Symbian OS UI system. When a file system needs to raise a user notification,it creates a session with the notifier server and issues a request on it,specifying the text for the dialogue box.
Until the user has responded tothe notification, and the request completes back to the file server, thedrive thread on which the error occurred is suspended. During this timethe file server is unable to process any other requests for that drive. Oncethe notification has completed, the original operation can be reattemptedif needed – for example if the user replaced the disk and selected the‘‘retry’’ dialogue button.Since the EKA2 file server has a separate thread per drive, the processing of requests on unaffected drives can continue as normal while anotification is active. It is not so simple to support user notification on theEKA1 version of F32. Here, because it has only a single thread, the fileserver has to nest its active scheduler so that it can accept a limited set ofother requests while the notification is being handled.File server clients can enable or disable critical notifiers on a persession basis using the method RFs::SetNotifyUser().
The defaultstate is for notifiers to be enabled.9.4.4 The read-only file system (ROFS)The read-only file system is part of the scheme used to support the storageof code (that is, ROM components) on non-XIP media such as NANDFlash.9.4.4.1 The core OS imageAs I mentioned in Section 9.4.3.3, NAND Flash devices are not byteaddressable, and they can only be read or written in page-sized units.As a result, they do not support code execute in place (XIP). This meansthat we need a RAM-shadowing scheme for code stored on NANDdevices – the code must be read from the Flash into RAM from where itis then executed.
![](https://s.studizba.com/z.php?f=/templates/si/i/noavatar.png&w=100&h=100&t=1"){kind=avatar}
