Re: UBIFS: Is it possible to get the compressed size of a file?

[Artem Bityutskiy <dedekind1@gmail.com>]

Hi Markus,

On Thu, 2014-12-18 at 12:08 +0100, markus.heininger@online.de wrote:
> in our system we´re using ring buffers where it is necessary to
> remove old files from certain directories when the physical usage
> of each directory is above a certain level which is different for each 
> folder.
> 
> Evaluating the output of "df" after write access might be difficult
> since there are several concurrent writing processes.
> 
> But many thanks for your answer, it seems that there is no easy
> way to get the information needed and we must investigate further on
> our own.

Yes, no easy way, but I think implementing what you need is possible. I
do not have plans and time to work on this, but I can help by giving
advises and review.

The question has 2 major parts.

1. The interface
2. The implementation


For the former, one need to carefully investigate if there is something
like this already implemented for other file-systems. I think btrfs may
have it. If it is, then UBIFS should use similar interface, probably.

And whatever is the interface choice, it should be discussed in the
linux-fsdevel@vger.kernel.org mailing list, which I am CCing.


For the latter, I'd suggest to try this.

a. 'struct ubifs_ino_node' has unused space, use it to add the
compressed size field.
b. maintain this field
c. this field will only be correct for the part of the file which are on
the media. The dirty data in the page cache has not yet been compressed,
so we do not know its compressed size yet.
e. when user asks for the compressed size, you have to sync the inode
first, in order to make sure the compressed size is correct.

And the implementation should be backward-compatible. That is, if new
driver mounts the old media, you return something predicatable. I guess
uncompressed size could be it.


Hope this helps,
Artem.

--
To unsubscribe from this list: send the line "unsubscribe linux-fsdevel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html