yaffs2 leaky, does not release blocks on rm

33 views
Skip to first unread message

luke

unread,
Jan 22, 2009, 2:41:54 AM1/22/09
to android-platform
I am trying to replace Browser.apk in /system without reflashing my
system.img. Sometimes I can just do "adb shell rm /system/app/
Browser.apk" then "adb push Browser.apk /system/app" and it upgrades
the package fine. Other times the file is deleted but the space is
not freed, and when I do the adb push, it tells me there is no space
left on the device. Rebooting does not help. df seems to confirm
that the space has been irretrievably lost.

I understand that /system is on an MTD, but doesn't yaffs2 wrap some
of the nasty details of working with these (erase blocks etc.)?

Do I need to do a GC? Can I manually trigger a GC with yaffs2? If
not, why is the GC not firing when the space is low?

How can I reclaim this space? Do I just have to re-flash? If so,
what is the point of being able to re-mount /system as rw?

Or is it just a yaffs2 bug? Something like this:
http://osdir.com/ml/linux.file-systems.yaffs/2005-10/msg00004.html ?

Or is it just part and parcel of working with MTDs, i.e.
http://lkml.indiana.edu/hypermail/linux/kernel/0308.1/0088.html ?

Jean-Baptiste Queru

unread,
Jan 22, 2009, 8:30:54 AM1/22/09
to android-...@googlegroups.com
-Believed to be a yaffs2 bug or a bug in the way android uses yaffs2
(I'm not an expert). Involves unlinking open files for sure, I've
heard that letting the device go to sleep had some impact.

-Especially visible for apks, as they tend to be large, and as the
system server tends to keep them open a long time (and possibly more
than it should - there's a bug assigned to me about that).

-There's a workaround posted somewhere, involves rebooting and pulling
the battery during the boot process before the device has had a chance
to go to sleep. I'm not 100% sure of the details, they've been posted
on various groups already.

JBQ

--
Jean-Baptiste M. "JBQ" Queru
Android Engineer, Google.

San Mehat

unread,
Jan 22, 2009, 9:16:13 AM1/22/09
to android-...@googlegroups.com
On Thu, Jan 22, 2009 at 5:30 AM, Jean-Baptiste Queru <j...@google.com> wrote:
>
> -Believed to be a yaffs2 bug or a bug in the way android uses yaffs2
> (I'm not an expert). Involves unlinking open files for sure, I've
> heard that letting the device go to sleep had some impact.
>
> -Especially visible for apks, as they tend to be large, and as the
> system server tends to keep them open a long time (and possibly more
> than it should - there's a bug assigned to me about that).
>
> -There's a workaround posted somewhere, involves rebooting and pulling
> the battery during the boot process before the device has had a chance
> to go to sleep. I'm not 100% sure of the details, they've been posted
> on various groups already.
>

Please make sure you remove your SD card before pulling the battery.


> JBQ
>
> On Wed, Jan 21, 2009 at 11:41 PM, luke <luke....@gmail.com> wrote:
>>
>> I am trying to replace Browser.apk in /system without reflashing my
>> system.img. Sometimes I can just do "adb shell rm /system/app/
>> Browser.apk" then "adb push Browser.apk /system/app" and it upgrades
>> the package fine. Other times the file is deleted but the space is
>> not freed, and when I do the adb push, it tells me there is no space
>> left on the device. Rebooting does not help. df seems to confirm
>> that the space has been irretrievably lost.
>>
>> I understand that /system is on an MTD, but doesn't yaffs2 wrap some
>> of the nasty details of working with these (erase blocks etc.)?
>>
>> Do I need to do a GC? Can I manually trigger a GC with yaffs2? If
>> not, why is the GC not firing when the space is low?
>>
>> How can I reclaim this space? Do I just have to re-flash? If so,
>> what is the point of being able to re-mount /system as rw?
>>
>> Or is it just a yaffs2 bug? Something like this:
>> http://osdir.com/ml/linux.file-systems.yaffs/2005-10/msg00004.html ?
>>
>> Or is it just part and parcel of working with MTDs, i.e.
>> http://lkml.indiana.edu/hypermail/linux/kernel/0308.1/0088.html ?
>>
>
>
>
> --
> Jean-Baptiste M. "JBQ" Queru
> Android Engineer, Google.
>

--
----------
San Mehat
Staff Software Engineer
Google Inc.
o: 650-253-7422
c: 408-382-1249
s...@google.com

Luke Hutchison

unread,
Jan 22, 2009, 9:58:22 AM1/22/09
to android-...@googlegroups.com
On Thu, Jan 22, 2009 at 8:30 AM, Jean-Baptiste Queru <j...@google.com> wrote:
-Believed to be a yaffs2 bug or a bug in the way android uses yaffs2
(I'm not an expert). Involves unlinking open files for sure, I've
heard that letting the device go to sleep had some impact.

My understanding is that when a file is open, Linux increments the inode refcount for the file by one; when it in unlinked, the link from the containing dir to the file is removed so the refcount is decremented, but the refcount is still greater than zero because of the in-memory link to the file.  With most file systems the inode refcount is probably flushed out to disk regularly, but that almost certainly doesn't happen with yaffs2 because of having to erase and rewrite an entire block just to write a few bytes.  Sounds like what is happening is that on sleep/reboot, the in-memory dirty inode refcount is not flushed out to disk either, so the block is never freed.  Somehow doing a sleep/wake cycle overwrites the dirty data, and/or possibly doing a reboot doesn't flush it out to disk.

Also, it looks like yaffs2's GC operation can only reclaim space when nodes are added to the "soft delete" list, that is probably not happening here because the node is not "soft deleted" until the file is closed.  I'm guessing there's no fsck.yaffs2 that looks for dirty blocks?


On Thu, Jan 22, 2009 at 9:16 AM, San Mehat <s...@google.com> wrote:
Please make sure you remove your SD card before pulling the battery.

Why is that?

Reply all
Reply to author
Forward
0 new messages