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

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



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.
--
To unsubscribe from this list: send the line "unsubscribe linux-fsdevel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html




[Index of Archives]     [Linux Ext4 Filesystem]     [Union Filesystem]     [Filesystem Testing]     [Ceph Users]     [Ecryptfs]     [AutoFS]     [Kernel Newbies]     [Share Photos]     [Security]     [Netfilter]     [Bugtraq]     [Yosemite News]     [MIPS Linux]     [ARM Linux]     [Linux Security]     [Linux Cachefs]     [Reiser Filesystem]     [Linux RAID]     [Samba]     [Device Mapper]     [CEPH Development]
  Powered by Linux