LZO support

[Tomeu Vizoso]

On Mon, Jul 14, 2008 at 7:07 PM, Erik Garrison <erik at laptop.org> wrote:
> On Mon, Jul 14, 2008 at 12:50:26PM -0400, Chris Ball wrote:
>> Hi,
>>
>>    >> I prefer aiming at #2886 ("Some files shouldn't be compressed by
>>    >> jffs2"), which goes a long way to solving the user problems
>>    >> without introducing the logistical cost of LZO support in OFW or
>>    >> partitions.
>>
>>    > How would this work? Should we create an empty file, set an xattr
>>    > and then start writing? If so, we should think about how we can
>>    > modify all sw to do so. Alternatively, as in most cases data is
>>    > already compressed, perhaps would be better to not compress by
>>    > default - or let that process to zip the file with gzip :P.
>>
>> Deepak suggests (in #2886) using something like an O_NOCOMPRESSION flag
>> to open(2), which sounds fine to me.  We'd either pass it to Python's
>> open() (how?) or set it immediately after open with fcntl(, F_SETFL, ).
>
> This approach will work provided all data is saved through the journal.
>
> Note that in at least one application (Record) which must write directly
> to the fs (afaik this is because of gstreamer).  Is this the only
> application with such a requirement?  If it is, are we expecting it to
> remain the only such application?
>
> In my opinion we should assume that other applications will have similar
> requirements, and work to implement compression at a lower level in the
> software stack so that we don't need to manage it at this level.
>
> That said, I personally support any small hack which we can push to the
> Journal to quickly implement a stopgap solution.

In the current DS API, activities write the file to the main fs, and
then ask the DS to move (preferred) or copy that file into the DS
space.

So we would need to modify all activities to set that flag after
opening the file and before writing to it.

Regards,

Tomeu