From: Richard Weinberger <richard@sigma-star.at>
To: Ricard Wanderlof <ricard.wanderlof@axis.com>
Cc: dedekind1@gmail.com, Jonas Holmberg <jonashg@axis.com>,
Linux mtd <linux-mtd@lists.infradead.org>,
Cristian Ionescu-Idbohrn <cii@axis.com>
Subject: Re: Actual usage of files in ubifs
Date: Tue, 12 Sep 2017 16:52:03 +0200 [thread overview]
Message-ID: <5426894.QDpU4CeFDX@blindfold> (raw)
In-Reply-To: <alpine.DEB.2.11.1709121106370.14549@lnxricardw1.se.axis.com>
Ricard,
Am Dienstag, 12. September 2017, 11:15:25 CEST schrieb Ricard Wanderlof:
> On Mon, 11 Sep 2017, Richard Weinberger wrote:
> > Am Montag, 11. September 2017, 17:44:09 CEST schrieb Artem Bityutskiy:
> > > > Good point. I was solely thinking along the lines of how much space
> > > > the
> > > > actual file occupied, not considering metadata. That would be a good
> > > > starting point. I'm guessing that for moderate file sizes the
> > > > metadata
> > > > would be relatively small compared to the file itself?
> > >
> > > I would think a "slow" version of this would not be that hard to
> > > implement - walk the index and sum up node sizes. Subtract header sizes
> > > if you do not want metadata.
> > >
> > > I am not sure what would be the API? Do other FSes implement something
> > > like this?
> >
> > I think a "show MTD usage by inode" should be implementable via debugfs.
> > Maybe, after a discussion on linux-fsdevel a per-file ioctl().
> >
> > But first I'd like to know more about the use-case and where to draw the
> > border. e.g. If a file as xattrs, do you also account them? UBIFS
> > modules xattrs via inodes. So, they have a rather huge space overhead.
>
> In our specific situation the use case is basically that given a specific
> set files (in the root file system), how much flash is actually needed,
> also considering that different types of files have different compression
> ratios depending on the content. I.e. a large text file might not hurt as
> much as a large binary since the former compresses better.
>
> So primarily it is the total amount needed for the whole file system, but
> it quickly comes down how much individual files consume. In our case it's
> not necessary to do the operation on a running file system, but in the
> more general case that might be more useful.
>
> I would think that this is something that is known somewhere inside
> mkfs.ubifs, or is the information too convoluted to be easily extractable?
Adding this to mkfs.ubifs shouldn't be a big deal.
And I agree your use case makes sense.
Do you want to send me a patch? :)
Thanks,
//richard
--
sigma star gmbh - Eduard-Bodem-Gasse 6 - 6020 Innsbruck - Austria
ATU66964118 - FN 374287y
next prev parent reply other threads:[~2017-09-12 14:52 UTC|newest]
Thread overview: 10+ messages / expand[flat|nested] mbox.gz Atom feed top
2017-09-11 9:47 Actual usage of files in ubifs Ricard Wanderlof
2017-09-11 14:55 ` Richard Weinberger
2017-09-11 15:18 ` Ricard Wanderlof
2017-09-11 15:44 ` Artem Bityutskiy
2017-09-11 19:57 ` Richard Weinberger
2017-09-12 9:15 ` Ricard Wanderlof
2017-09-12 14:52 ` Richard Weinberger [this message]
2017-09-15 22:08 ` Ricard Wanderlof
2017-09-16 6:32 ` Richard Weinberger
2017-09-18 6:37 ` Ricard Wanderlof
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=5426894.QDpU4CeFDX@blindfold \
--to=richard@sigma-star.at \
--cc=cii@axis.com \
--cc=dedekind1@gmail.com \
--cc=jonashg@axis.com \
--cc=linux-mtd@lists.infradead.org \
--cc=ricard.wanderlof@axis.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.