From: Duncan <1i5t5.duncan@cox.net>
To: linux-btrfs@vger.kernel.org
Subject: Re: btrfs quota issues
Date: Sat, 13 Aug 2016 23:05:50 +0000 (UTC) [thread overview]
Message-ID: <pan$541a$1c388cce$2546386a$4951cf94@cox.net> (raw)
In-Reply-To: CAGj_d3BTkO_cUJ2Lihi2dnD+oJUFTfqHeEBm2i2vVhS=1Y9MrQ@mail.gmail.com
Rakesh Sankeshi posted on Fri, 12 Aug 2016 08:47:13 -0700 as excerpted:
> Another question I had was, is there any way to check what's the
> directory/file sizes prior to compression and how much copression btrfs
> did, etc? Basicaly some stats around compression and/or dedupe from
> btrfs.
There's some dedupe reportes I've seen posted, that basically show shared
vs. unique extents, but that's out of both my area of usage /and/ my area
of interest, so that's pretty much all I can say on that.
Compression... AFAIK there's no nice neat admin-level command for it
(yet?), but it's possible to get the raw information via filefrag -v.
The output is a list of extents for the file in question, with both their
(uncompressed) size and start/end addresses. If the size is greater than
the space they take up based on their start/end addresses, then obviously
that extent is compressed. People have posted python scripts and the
like that process that information into something higher level that an
admin could digest, but I believe you'll have to mine the list archives
to find them.
In the context of filefrag, it is worth mentioning, however, that btrfs
compression blocks are 128 KiB in (uncompressed) size, and that filefrag
considers each such reported block its own extent, even where it's
contiguous with the next one. Put another way, filefrag doesn't
understand btrfs compression, tho it's possible to use its output to
figure out whether a file is compressed or not, and by how much.
It's also relatively easy to quickly scan the filefrag output to see if
all the extents are 128 KiB in size and consider that compressed, and/or
to divide the file size by 128 KiB and see if that matches the number of
reported extents, considering it compressed if so. For a few one-off
files, that's easy enough to do manually, but you'd definitely want to
automate the process if you wanted that information on more than a few
individual files.
--
Duncan - List replies preferred. No HTML msgs.
"Every nonfree program has a lord, a master --
and if you use the program, he is your master." Richard Stallman
next prev parent reply other threads:[~2016-08-14 9:14 UTC|newest]
Thread overview: 13+ messages / expand[flat|nested] mbox.gz Atom feed top
2016-08-11 17:32 btrfs quota issues Rakesh Sankeshi
2016-08-11 19:13 ` Duncan
2016-08-12 15:47 ` Rakesh Sankeshi
2016-08-13 23:05 ` Duncan [this message]
2016-08-15 2:11 ` Qu Wenruo
2016-08-15 19:11 ` Rakesh Sankeshi
2016-08-16 1:01 ` Qu Wenruo
2016-08-16 16:05 ` Rakesh Sankeshi
2016-08-16 23:33 ` Rakesh Sankeshi
2016-08-17 0:09 ` Tim Walberg
2016-08-17 0:56 ` Qu Wenruo
2016-08-23 18:38 ` Rakesh Sankeshi
2016-08-26 1:52 ` Qu Wenruo
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='pan$541a$1c388cce$2546386a$4951cf94@cox.net' \
--to=1i5t5.duncan@cox.net \
--cc=linux-btrfs@vger.kernel.org \
/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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).