From: David Sterba <dsterba@suse.cz>
To: hujianyang <hujianyang@huawei.com>
Cc: Andreas Dilger <adilger@dilger.ca>,
Linux Filesystem Development List <linux-fsdevel@vger.kernel.org>,
linux-mtd@lists.infradead.org,
"markus.heininger@online.de" <markus.heininger@online.de>,
dedekind1@gmail.com
Subject: Re: UBIFS: Is it possible to get the compressed size of a file?
Date: Thu, 26 Mar 2015 15:19:16 +0100 [thread overview]
Message-ID: <20150326141916.GO20767@suse.cz> (raw)
In-Reply-To: <54F16EC2.3070703@huawei.com>
On Sat, Feb 28, 2015 at 03:31:14PM +0800, hujianyang wrote:
> > http://lwn.net/Articles/607552/
> > http://thread.gmane.org/gmane.comp.file-systems.btrfs/37312
> >
> > I'm not sure what happened to that patch series - I was looking forward
> > to it landing, and it was in very good shape I think.
> Since the *fe_phys_length* of fiemap_extent is not import to mainline,
> current fiemap can only report logical data length of an extent. Regret
> to say, it's no use for getting the compressed size of a file in UBIFS.
Yeah, not the best example how a patchset should be pushed. I'll try to
get back soon to it given the almost-ready state and another potential
user of the interface.
> So could we use a simply method? just a private ioctl which scan the tnc tree
> and report the compressed size of a UBIFS file? I found an old patch for Btrfs,
> but it is not import to mainline.
>
> https://patchwork.kernel.org/patch/117782/
This was at the beginning of the fiemap extensions. I've picked that
patch, updated and sent
http://www.mail-archive.com/linux-btrfs%40vger.kernel.org/msg14371.html
but it was not merged. We've discussed that and came to conclusion that
a special ioctl was not the right approach when we could extend the
existing interfaces. The ioctl was iterating over all extents and just
summing some numbers, effectively repeating the core code of fiemap.
Though you're (relatively) free to introduce private ioctls for your
filesystem, I'd rather not recommend that. Once an ioctl is introduced,
you have to support it forever, the deprecation periods span several
years.
> Further, for both fiemap or this private ioctl method, current tnc tree lookup
> mechanism seems always copying the whole ubifs node, but only the header of a
> node is used in this case. Do we have a way to only read part of a node from
> tnc tree?
I don't understand the details, but this seems that even the private
ioctl would help too much even if you'd be more free to do some
performance optimizations that would not fit fiemap.
WARNING: multiple messages have this Message-ID (diff)
From: David Sterba <dsterba@suse.cz>
To: hujianyang <hujianyang@huawei.com>
Cc: Andreas Dilger <adilger@dilger.ca>,
dedekind1@gmail.com,
"markus.heininger@online.de" <markus.heininger@online.de>,
linux-mtd@lists.infradead.org,
Linux Filesystem Development List <linux-fsdevel@vger.kernel.org>
Subject: Re: UBIFS: Is it possible to get the compressed size of a file?
Date: Thu, 26 Mar 2015 15:19:16 +0100 [thread overview]
Message-ID: <20150326141916.GO20767@suse.cz> (raw)
In-Reply-To: <54F16EC2.3070703@huawei.com>
On Sat, Feb 28, 2015 at 03:31:14PM +0800, hujianyang wrote:
> > http://lwn.net/Articles/607552/
> > http://thread.gmane.org/gmane.comp.file-systems.btrfs/37312
> >
> > I'm not sure what happened to that patch series - I was looking forward
> > to it landing, and it was in very good shape I think.
> Since the *fe_phys_length* of fiemap_extent is not import to mainline,
> current fiemap can only report logical data length of an extent. Regret
> to say, it's no use for getting the compressed size of a file in UBIFS.
Yeah, not the best example how a patchset should be pushed. I'll try to
get back soon to it given the almost-ready state and another potential
user of the interface.
> So could we use a simply method? just a private ioctl which scan the tnc tree
> and report the compressed size of a UBIFS file? I found an old patch for Btrfs,
> but it is not import to mainline.
>
> https://patchwork.kernel.org/patch/117782/
This was at the beginning of the fiemap extensions. I've picked that
patch, updated and sent
http://www.mail-archive.com/linux-btrfs%40vger.kernel.org/msg14371.html
but it was not merged. We've discussed that and came to conclusion that
a special ioctl was not the right approach when we could extend the
existing interfaces. The ioctl was iterating over all extents and just
summing some numbers, effectively repeating the core code of fiemap.
Though you're (relatively) free to introduce private ioctls for your
filesystem, I'd rather not recommend that. Once an ioctl is introduced,
you have to support it forever, the deprecation periods span several
years.
> Further, for both fiemap or this private ioctl method, current tnc tree lookup
> mechanism seems always copying the whole ubifs node, but only the header of a
> node is used in this case. Do we have a way to only read part of a node from
> tnc tree?
I don't understand the details, but this seems that even the private
ioctl would help too much even if you'd be more free to do some
performance optimizations that would not fit fiemap.
next prev parent reply other threads:[~2015-03-26 14:19 UTC|newest]
Thread overview: 106+ messages / expand[flat|nested] mbox.gz Atom feed top
2014-12-12 8:10 UBIFS: Is it possible to get the compressed size of a file? markus.heininger
2014-12-17 6:22 ` hujianyang
2014-12-18 11:08 ` Aw: " markus.heininger
2015-02-02 9:33 ` Artem Bityutskiy
2015-02-02 9:33 ` Artem Bityutskiy
2015-02-03 5:45 ` Andreas Dilger
2015-02-03 5:45 ` Andreas Dilger
2015-02-03 9:07 ` Artem Bityutskiy
2015-02-03 9:07 ` Artem Bityutskiy
2015-02-28 7:31 ` hujianyang
2015-02-28 7:31 ` hujianyang
2015-03-26 14:19 ` David Sterba [this message]
2015-03-26 14:19 ` David Sterba
-- strict thread matches above, loose matches on Subject: below --
2015-03-10 12:03 OpenStack - Libvirt+Xen CI overview Bob Ball
2015-03-16 15:09 ` OpenStack - Libvirt+Xen CI overview : anyone interested in a walk/through or presentation on how it works Lars Kurth
2015-03-16 18:00 ` OpenStack - Libvirt+Xen CI overview Konrad Rzeszutek Wilk
2015-03-17 12:52 ` Dario Faggioli
2015-03-17 11:14 ` George Dunlap
2015-03-17 14:22 ` Jim Fehlig
2015-03-17 15:51 ` Alvin Starr
2015-03-18 13:12 ` OpenStack - Libvirt+Xen CI overview : anyone interested in a walk/through or presentation on how it works Lars Kurth
2015-03-18 14:37 ` Wei Liu
2015-03-24 18:17 ` Lars Kurth
2015-03-25 10:08 ` Ian Campbell
2015-03-25 10:09 ` Bob Ball
2015-03-25 12:26 ` Alvin Starr
2015-04-22 10:03 ` Lars Kurth
2015-06-04 17:12 ` Bob Ball
2015-06-05 11:47 ` Lars Kurth
2015-06-08 12:52 ` Bob Ball
2015-06-10 14:25 ` Bob Ball
2015-06-15 16:26 ` Bob Ball
[not found] <10286402.11.1422626774586.JavaMail.kraghavendra@Raghavendra>
2015-01-30 14:08 ` Yocto-custom kernel build issue Raghavendra Kakarla
2015-01-30 16:34 ` Bruce Ashfield
2015-02-02 10:00 ` Raghavendra Kakarla
2015-02-03 12:40 ` yocto-custom-kernel issue Raghavendra Kakarla
2015-02-03 13:17 ` Sven Ebenfeld
2015-02-03 15:37 ` Bruce Ashfield
2015-02-05 8:56 ` MIPS32r2 little endian bsp Raghavendra Kakarla
2015-02-06 15:04 ` Mark Hatle
2015-02-10 8:17 ` Yocto-custom kernel build issue Raghavendra Kakarla
2015-02-10 11:00 ` Paul Eggleton
[not found] ` <2974616.30.1423571125144.JavaMail.kraghavendra@Raghavendra>
2015-02-10 13:36 ` Paul Eggleton
2015-02-11 4:55 ` Raghavendra Kakarla
2015-02-11 9:30 ` Paul Eggleton
2015-02-11 10:00 ` Raghavendra Kakarla
2015-03-03 5:41 ` SDK generation issue Raghavendra Kakarla
2015-03-03 9:37 ` Paul Eggleton
2015-03-03 10:26 ` Raghavendra Kakarla
2015-03-03 10:31 ` Paul Eggleton
2015-03-03 11:55 ` Raghavendra Kakarla
2015-03-03 12:10 ` Paul Eggleton
2015-03-03 12:17 ` Raghavendra Kakarla
2015-03-03 13:16 ` Paul Eggleton
2015-03-10 4:21 ` Difference b/w yocto kernels and normal linux.org kernels Raghavendra Kakarla
2015-03-10 4:33 ` Khem Raj
2015-03-10 4:45 ` Nicholas Krause
2015-03-13 8:14 ` Raghavendra Kakarla
2015-03-13 8:53 ` Paul Eggleton
2015-03-13 9:05 ` Albert K
2015-03-13 9:12 ` Paul Eggleton
2015-04-03 6:04 ` Raghavendra Kakarla
2015-03-03 17:55 ` SDK generation issue Jim Rafert
2014-11-06 13:27 lots of connections in SYN_RECV state Puneet Agarwal
2014-11-06 14:30 ` Silvan Jegen
2014-11-06 15:15 ` Puneet Agarwal
2014-11-06 15:58 ` Silvan Jegen
2014-11-07 15:49 ` Dave Tian
2014-11-07 16:58 ` Valdis.Kletnieks at vt.edu
2014-11-07 23:48 ` Dave Tian
2014-11-07 17:41 ` Puneet Agarwal
2014-11-07 18:10 ` Valdis.Kletnieks at vt.edu
2014-11-08 2:05 ` Puneet Agarwal
2012-03-19 20:59 Linking two recipes simran singh
2012-03-19 21:22 ` Richard Purdie
2012-03-19 21:33 ` simran singh
2012-03-19 21:39 ` Christopher Larson
2012-03-19 21:57 ` simran singh
2012-03-19 21:59 ` Christopher Larson
2012-03-19 22:10 ` simran singh
2012-03-19 22:54 ` Richard Purdie
2012-03-20 19:25 ` simran singh
2012-04-07 3:44 ` Khem Raj
2005-01-11 9:28 [U-Boot-Users] PCI, Ethernet, IXDP425 Ara Avanesyan
2005-01-11 22:40 ` Wolfgang Denk
2005-01-12 6:18 ` [U-Boot-Users] " Ara Avanesyan
2005-01-12 6:41 ` Rodel Miguel
2005-01-12 7:41 ` Ara Avanesyan
2005-01-12 8:08 ` Ing.Gianfranco Morandi
2005-01-12 9:01 ` Wolfgang Denk
2005-01-12 9:32 ` Ara Avanesyan
2005-01-12 10:13 ` Anders Larsen
2005-01-12 14:16 ` Wolfgang Denk
2005-01-12 14:16 ` Wolfgang Denk
2005-01-12 15:07 ` Ara Avanesyan
2003-11-12 17:23 [U-Boot-Users] [PATCH] fix the ARM memory layout Anders Larsen
2003-11-12 19:52 ` Kyle Harris
2003-11-13 9:14 ` Anders Larsen
2003-11-13 14:19 ` Kyle Harris
2003-11-21 3:52 ` Kyle Harris
2003-11-21 7:47 ` Anders Larsen
2003-11-21 8:13 ` Wolfgang Denk
2003-12-07 0:17 ` Wolfgang Denk
2003-12-07 17:03 ` Anders Larsen
2004-01-09 11:14 ` Anders Larsen
2004-02-08 19:36 ` Wolfgang Denk
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=20150326141916.GO20767@suse.cz \
--to=dsterba@suse.cz \
--cc=adilger@dilger.ca \
--cc=dedekind1@gmail.com \
--cc=hujianyang@huawei.com \
--cc=linux-fsdevel@vger.kernel.org \
--cc=linux-mtd@lists.infradead.org \
--cc=markus.heininger@online.de \
/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.