<div class="gmail_quote">Hi,</div><div class="gmail_quote"><br></div><div class="gmail_quote">I was just looking into this and the issue with SD cards' random write performance intrigued me in this particular case.</div>

<div class="gmail_quote">Isn't recording being performed sequentially, hence no lag problem? At least, it should be somewhat mitigated, filesystem might be causing problems?</div><div class="gmail_quote"><br></div><div class="gmail_quote">

Anyhow, I have been looking into how to go around the random write problem and NILFS2 popped up. In theory it seems a very capable way of having a whole lot better performance, as it should only perform sequential writes(unfortunately only partially). Anyone tried it before choosing ext3?</div>

<div class="gmail_quote"><br></div><div class="gmail_quote">I have still not gotten to backuping the fs and moving it to NILFS2. It even has SSD options and can suspend the garbage collector within some criteria, helping alleviate the wear issue. </div>

<div class="gmail_quote"><br></div><div class="gmail_quote">Best regards,</div><div class="gmail_quote">Tiago</div><div class="gmail_quote"><br></div><div class="gmail_quote"><br></div><div class="gmail_quote">On Thu, May 6, 2010 at 6:40 AM, Zarro Boogs per Child <span dir="ltr"><<a href="mailto:bugtracker@laptop.org">bugtracker@laptop.org</a>></span> wrote:<br>

<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;"><div class="im">#10045: XO-1.5 Record audio/video are out of sync with each other<br>
---------------------------------------+------------------------------------<br>
           Reporter:  wad              |       Owner:  dsd<br>
               Type:  defect           |      Status:  new<br>
           Priority:  high             |   Milestone:  1.5-software-update<br>
          Component:  record-activity  |     Version:  Development build as of this date<br>
         Resolution:                   |    Keywords:  camera record XO-1.5<br>
        Next_action:  diagnose         |    Verified:  0<br>
Deployment_affected:                   |   Blockedby:<br>
           Blocking:                   |<br>
---------------------------------------+------------------------------------<br>
<br>
</div>Comment(by Quozl):<br>
<br>
 A significant improvement in video recording is achieved by moving the<br>
 instance directory for the Record activity off the SD card.<br>
<br>
 The result was no significant pauses in video motion during recording, and<br>
 a much more predictable A/V latency.<br>
<br>
 The downside is restricted recording time.<br>
<br>
 This suggests that the current problems with recording are due to the SD<br>
 writes.  See #9688 (terrible SD write performance: wontfix), #9995<br>
 (optimise kernel write block size), and #10112 (GUI freezes on fsync).<br>
<br>
 While this is not the best way of doing it, this is the method I used:<br>
<br>
  * start Record,<br>
  * copy the directory to a large enough tmpfs,<br>
  {{{<br>
 cd .sugar/default<br>
 rsync -a org.laptop.RecordActivity /dev/shm<br>
 }}}<br>
  * remove the old directory and create a symlink,<br>
  {{{<br>
 rm -rf org.laptop.RecordActivity && \<br>
 ln -s /dev/shm/org.laptop.RecordActivity<br>
 }}}<br>
  * continue using the Record activity.<br>
<br>
 (This symlink persists until removed ... and since /dev/shm is empty next<br>
 boot the Record activity will fail to start.)<br>
<font color="#888888"><br>
--<br>
Ticket URL: <<a href="http://dev.laptop.org/ticket/10045#comment:25" target="_blank">http://dev.laptop.org/ticket/10045#comment:25</a>><br>
</font><div><div></div><div class="h5">One Laptop Per Child <<a href="http://laptop.org/" target="_blank">http://laptop.org/</a>><br>
OLPC bug tracking system<br>
</div></div></blockquote></div><br>