--- a/Symbian3/PDK/Source/GUID-5B24741C-7CE0-58E8-98C9-1D1CACCD476F.dita Thu Mar 11 15:24:26 2010 +0000
+++ b/Symbian3/PDK/Source/GUID-5B24741C-7CE0-58E8-98C9-1D1CACCD476F.dita Thu Mar 11 18:02:22 2010 +0000
@@ -1,100 +1,100 @@
-<?xml version="1.0" encoding="utf-8"?>
-<!-- Copyright (c) 2007-2010 Nokia Corporation and/or its subsidiary(-ies) All rights reserved. -->
-<!-- This component and the accompanying materials are made available under the terms of the License
-"Eclipse Public License v1.0" which accompanies this distribution,
-and is available at the URL "http://www.eclipse.org/legal/epl-v10.html". -->
-<!-- Initial Contributors:
- Nokia Corporation - initial contribution.
-Contributors:
--->
-<!DOCTYPE concept
- PUBLIC "-//OASIS//DTD DITA Concept//EN" "concept.dtd">
-<concept id="GUID-5B24741C-7CE0-58E8-98C9-1D1CACCD476F" xml:lang="en"><title>Fair
-Scheduling and File Caching</title><shortdesc>This document describes the fair scheduling and file caching features
-of the File Server.</shortdesc><prolog><metadata><keywords/></metadata></prolog><conbody>
-<section id="GUID-CBF527A2-EF30-5D4D-9BF4-631748315BE9"><title>Fair scheduling</title><p>The
-current design of the file server supports the processing of client requests
-concurrently, as long as those requests are made to different drives in the
-system. For example, a read operation may take place on the NAND user area
-partition while a write operation to the MMC card takes place concurrently. </p><p>However,
-requests to the same drive are serialized on a first-come first-served basis,
-which under some circumstances leads to bad user experience. For example:</p><ol>
-<li id="GUID-6550B420-5545-42C9-B304-9A8FA7D9DA01"><p>An incoming call arrives
-while a large video file is being written to the NAND user area by an application
-that writes the file in very large chunks.</p></li>
-<li id="GUID-7B08B626-E610-448B-917C-CB6CC127F2B9"><p>In order to display
-the caller’s details, the phone needs to read from the contacts database which
-is also stored on the NAND user area.</p></li>
-<li id="GUID-3A42569B-66CF-420F-A09D-F02A6BA4E4F9"><p>The write operation
-takes a very long time to complete, so the call is lost.</p></li>
-</ol><p> This is one of many scenarios where the single threaded nature of
-the file server may lead to unresponsive behavior. In order to improve the
-responsiveness of the system, the Symbian platform implements a fair scheduling
-policy that splits up large requests into more manageable chunks, thus providing
-clients of the file server with a more responsive system when the file server
-is under heavy load.</p><p>See <xref href="GUID-89BCF9A5-ABBD-5523-BA76-FDB00B806A30.dita#GUID-89BCF9A5-ABBD-5523-BA76-FDB00B806A30/GUID-450D57A3-928B-5389-B941-595DB20A7CEA">Enabling
-fair scheduling</xref>.</p></section>
-<section id="GUID-84C18F69-D193-4010-A9B2-B533FC6ACF51"><title>Read caching</title><p>Read caching aims to improve file server
-performance by addressing the following use case: <ul>
-<li><p>A client (or multiple clients) issues repeated requests to read data
-from the same locality within a file. Data that was previously read (and is
-still in the cache) can be returned to the client without continuously re-reading
-the data from the media. </p></li>
-</ul></p><note>Read caching is of little benefit for clients/files that are
-typically accessed sequentially in large blocks and never re-read.</note><p>There
-may be a small degradation in performance on some media due to the overhead
-of copying the data from the media into the file cache. To some extent this
-may be mitigated by the affects of read-ahead, but this clearly does not affect
-large (>= 4K) reads and/or non-sequential reads. It should also be noted that
-any degradation may be more significant for media where the read is entirely
-synchronous (for example, NAND on the H4 HRP), because there is no scope for
-a read-ahead to be running in the file server drive thread at the same time
-as reads are being satisfied in the context of the file server’s main thread.</p></section>
-<section id="GUID-7C6E6FDB-1419-4A8E-82F8-74EE6E62D468"><title>Demand paging effects</title><p>When ROM paging is enabled,
-the kernel maintains a <i>live list</i> of pages that are currently being
-used to store demand paged content. It is important to realize that this list
-also contains non-dirty pages belonging to the file cache. The implication
-of this is that reading some data into the file cache, or reading data already
-stored in the file cache, may result in code pages being evicted from the
-live list. </p><p>Having a large number of clients reading through
-or from the file cache can have an adverse effect on performance. For this
-reason it is probably not a good idea to set the <xref href="GUID-3B777E89-8E4C-3540-958F-C621741895C8.dita"><apiname>FileCacheSize</apiname></xref> property
-to too large a value – otherwise a single application reading a single large
-file through the cache is more likely to cause code page evictions if the
-amount of available RAM is restricted. See <xref href="GUID-EB2566BD-8F65-5A81-B215-E8B05CFE21C3.dita">Migration
-Tutorial: Demand Paging and Media Drivers</xref>.</p></section>
-<section id="GUID-9BCF8F2A-F919-4AC7-BA05-02CC763429C1"><title>Read-ahead caching</title><p>Clients that read data sequentially
-(particularly using small block lengths) impact system performance due to
-the overhead in requesting data from the media. Read-ahead caching addresses
-this issue by ensuring that subsequent small read operations may be satisfied
-from the cache after issuing a large request to read ahead data from the media.</p><p>Read-ahead
-caching builds on read caching by detecting clients that are performing streaming
-operations and speculatively reading ahead on the assumption that once the
-data is in the cache it is likely to be accessed in the near future, thus
-improving performance.</p><p>The number of bytes requested by the read-ahead
-mechanism is initially equal to double the client’s last read length or a
-page, for example, 4K (whichever is greater) and doubles each time the file
-server detects that the client is due to read outside of the extents of the
-read-ahead cache, up to a pre-defined maximum (128K). </p></section>
-<section id="GUID-976EE014-E3C3-42FD-8467-1D008DEC27FD"><title>Write caching</title><p>Write caching is implemented to perform
-a small level of write-back caching. This overcomes inefficiencies of clients
-that perform small write operations, thus taking advantage of media that is
-written on a block basis by consolidating multiple file updates into a single
-larger write as well as minimizing the overhead of metadata updates that the
-file system performs. </p><p>By implementing write back at the file level,
-rather than at the level of the block device, the possibility of file system
-corruption is removed as the robustness features provided by rugged FAT and
-LFFS are still applicable.</p><p>Furthermore, by disabling write back by default,
-allowing the licensee to specify the policy on a per drive basis, providing
-APIs on a per session basis and respecting Flush and Close operations, the
-risk of data corruption is minimized.</p><note>The possibility of data loss
-increases, but the LFFS file system already implements a simple write back
-cache of 4K in size so the impact of this should be minimal.</note><note>Write
-caching must be handled with care, as this could potentially result in loss
-of user data.</note><p>Database access needs special consideration as corruption
-may occur if the database is written to expect write operations to be committed
-to disk immediately or in a certain order (write caching may re-order write
-requests).</p><p>For these reasons, it is probably safer to leave write caching
-off by default and to consider enabling it on a per-application basis. See <xref href="GUID-89BCF9A5-ABBD-5523-BA76-FDB00B806A30.dita#GUID-89BCF9A5-ABBD-5523-BA76-FDB00B806A30/GUID-719C7E0C-790B-5C61-9EA8-E2687397340F">Enabling
-read and write caching</xref>.</p></section>
+<?xml version="1.0" encoding="utf-8"?>
+<!-- Copyright (c) 2007-2010 Nokia Corporation and/or its subsidiary(-ies) All rights reserved. -->
+<!-- This component and the accompanying materials are made available under the terms of the License
+"Eclipse Public License v1.0" which accompanies this distribution,
+and is available at the URL "http://www.eclipse.org/legal/epl-v10.html". -->
+<!-- Initial Contributors:
+ Nokia Corporation - initial contribution.
+Contributors:
+-->
+<!DOCTYPE concept
+ PUBLIC "-//OASIS//DTD DITA Concept//EN" "concept.dtd">
+<concept id="GUID-5B24741C-7CE0-58E8-98C9-1D1CACCD476F" xml:lang="en"><title>Fair
+Scheduling and File Caching</title><shortdesc>This document describes the fair scheduling and file caching features
+of the File Server.</shortdesc><prolog><metadata><keywords/></metadata></prolog><conbody>
+<section id="GUID-CBF527A2-EF30-5D4D-9BF4-631748315BE9"><title>Fair scheduling</title><p>The
+current design of the file server supports the processing of client requests
+concurrently, as long as those requests are made to different drives in the
+system. For example, a read operation may take place on the NAND user area
+partition while a write operation to the MMC card takes place concurrently. </p><p>However,
+requests to the same drive are serialized on a first-come first-served basis,
+which under some circumstances leads to bad user experience. For example:</p><ol>
+<li id="GUID-6550B420-5545-42C9-B304-9A8FA7D9DA01"><p>An incoming call arrives
+while a large video file is being written to the NAND user area by an application
+that writes the file in very large chunks.</p></li>
+<li id="GUID-7B08B626-E610-448B-917C-CB6CC127F2B9"><p>In order to display
+the caller’s details, the phone needs to read from the contacts database which
+is also stored on the NAND user area.</p></li>
+<li id="GUID-3A42569B-66CF-420F-A09D-F02A6BA4E4F9"><p>The write operation
+takes a very long time to complete, so the call is lost.</p></li>
+</ol><p> This is one of many scenarios where the single threaded nature of
+the file server may lead to unresponsive behavior. In order to improve the
+responsiveness of the system, the Symbian platform implements a fair scheduling
+policy that splits up large requests into more manageable chunks, thus providing
+clients of the file server with a more responsive system when the file server
+is under heavy load.</p><p>See <xref href="GUID-89BCF9A5-ABBD-5523-BA76-FDB00B806A30.dita#GUID-89BCF9A5-ABBD-5523-BA76-FDB00B806A30/GUID-450D57A3-928B-5389-B941-595DB20A7CEA">Enabling
+fair scheduling</xref>.</p></section>
+<section id="GUID-84C18F69-D193-4010-A9B2-B533FC6ACF51"><title>Read caching</title><p>Read caching aims to improve file server
+performance by addressing the following use case: <ul>
+<li><p>A client (or multiple clients) issues repeated requests to read data
+from the same locality within a file. Data that was previously read (and is
+still in the cache) can be returned to the client without continuously re-reading
+the data from the media. </p></li>
+</ul></p><note>Read caching is of little benefit for clients/files that are
+typically accessed sequentially in large blocks and never re-read.</note><p>There
+may be a small degradation in performance on some media due to the overhead
+of copying the data from the media into the file cache. To some extent this
+may be mitigated by the affects of read-ahead, but this clearly does not affect
+large (>= 4K) reads and/or non-sequential reads. It should also be noted that
+any degradation may be more significant for media where the read is entirely
+synchronous (for example, NAND on the H4 HRP), because there is no scope for
+a read-ahead to be running in the file server drive thread at the same time
+as reads are being satisfied in the context of the file server’s main thread.</p></section>
+<section id="GUID-7C6E6FDB-1419-4A8E-82F8-74EE6E62D468"><title>Demand paging effects</title><p>When ROM paging is enabled,
+the kernel maintains a <i>live list</i> of pages that are currently being
+used to store demand paged content. It is important to realize that this list
+also contains non-dirty pages belonging to the file cache. The implication
+of this is that reading some data into the file cache, or reading data already
+stored in the file cache, may result in code pages being evicted from the
+live list. </p><p>Having a large number of clients reading through
+or from the file cache can have an adverse effect on performance. For this
+reason it is probably not a good idea to set the <xref href="GUID-3B777E89-8E4C-3540-958F-C621741895C8.dita"><apiname>FileCacheSize</apiname></xref> property
+to too large a value – otherwise a single application reading a single large
+file through the cache is more likely to cause code page evictions if the
+amount of available RAM is restricted. See <xref href="GUID-EB2566BD-8F65-5A81-B215-E8B05CFE21C3.dita">Migration
+Tutorial: Demand Paging and Media Drivers</xref>.</p></section>
+<section id="GUID-9BCF8F2A-F919-4AC7-BA05-02CC763429C1"><title>Read-ahead caching</title><p>Clients that read data sequentially
+(particularly using small block lengths) impact system performance due to
+the overhead in requesting data from the media. Read-ahead caching addresses
+this issue by ensuring that subsequent small read operations may be satisfied
+from the cache after issuing a large request to read ahead data from the media.</p><p>Read-ahead
+caching builds on read caching by detecting clients that are performing streaming
+operations and speculatively reading ahead on the assumption that once the
+data is in the cache it is likely to be accessed in the near future, thus
+improving performance.</p><p>The number of bytes requested by the read-ahead
+mechanism is initially equal to double the client’s last read length or a
+page, for example, 4K (whichever is greater) and doubles each time the file
+server detects that the client is due to read outside of the extents of the
+read-ahead cache, up to a pre-defined maximum (128K). </p></section>
+<section id="GUID-976EE014-E3C3-42FD-8467-1D008DEC27FD"><title>Write caching</title><p>Write caching is implemented to perform
+a small level of write-back caching. This overcomes inefficiencies of clients
+that perform small write operations, thus taking advantage of media that is
+written on a block basis by consolidating multiple file updates into a single
+larger write as well as minimizing the overhead of metadata updates that the
+file system performs. </p><p>By implementing write back at the file level,
+rather than at the level of the block device, the possibility of file system
+corruption is removed as the robustness features provided by rugged FAT and
+LFFS are still applicable.</p><p>Furthermore, by disabling write back by default,
+allowing the licensee to specify the policy on a per drive basis, providing
+APIs on a per session basis and respecting Flush and Close operations, the
+risk of data corruption is minimized.</p><note>The possibility of data loss
+increases, but the LFFS file system already implements a simple write back
+cache of 4K in size so the impact of this should be minimal.</note><note>Write
+caching must be handled with care, as this could potentially result in loss
+of user data.</note><p>Database access needs special consideration as corruption
+may occur if the database is written to expect write operations to be committed
+to disk immediately or in a certain order (write caching may re-order write
+requests).</p><p>For these reasons, it is probably safer to leave write caching
+off by default and to consider enabling it on a per-application basis. See <xref href="GUID-89BCF9A5-ABBD-5523-BA76-FDB00B806A30.dita#GUID-89BCF9A5-ABBD-5523-BA76-FDB00B806A30/GUID-719C7E0C-790B-5C61-9EA8-E2687397340F">Enabling
+read and write caching</xref>.</p></section>
</conbody></concept>
\ No newline at end of file