From mboxrd@z Thu Jan 1 00:00:00 1970 From: Artem Bityutskiy Subject: Re: UBIFS: Is it possible to get the compressed size of a file? Date: Mon, 02 Feb 2015 11:33:30 +0200 Message-ID: <1422869610.8637.352.camel@sauron.fi.intel.com> References: , <54912109.50505@huawei.com> Reply-To: dedekind1@gmail.com Mime-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: QUOTED-PRINTABLE Cc: hujianyang , linux-mtd@lists.infradead.org, linux-fsdevel@vger.kernel.org To: "markus.heininger@online.de" Return-path: Received: from mga02.intel.com ([134.134.136.20]:43714 "EHLO mga02.intel.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1754434AbbBBJdf (ORCPT ); Mon, 2 Feb 2015 04:33:35 -0500 In-Reply-To: Sender: linux-fsdevel-owner@vger.kernel.org List-ID: Hi Markus, On Thu, 2014-12-18 at 12:08 +0100, markus.heininger@online.de wrote: > in our system we=C2=B4re 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 eac= h=20 > folder. >=20 > Evaluating the output of "df" after write access might be difficult > since there are several concurrent writing processes. >=20 > 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 =46or the former, one need to carefully investigate if there is somethi= ng 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. =46or 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 o= n 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