Re: [PATCH][BTRFS-PROGS] btrfs filesystem disk-usage
Hi, Thanks for this patch. Personally, i don't mind any of the propositions as the developpement is still in progress and may be adapted. Furthermore, as Roman said, df is more well known for unix users. Thanks to your work on that, i've started developing a bunch of scripts for monitoring btrfs disk usage (and also for monitoring snapper if anyone use it) through nagios. Regards. Sébastien Roman Mamedov a écrit : On Wed, 3 Oct 2012 08:22:06 +0200 Goffredo Baroncelli wrote: On Wed, Oct 3, 2012 at 1:46 AM, Chris Mason wrote: [...] > I like it, thanks. Could you please update btrfs fi df to show this > instead of adding a new command though? Hi Chris, no problem to update the patches, however I have one suggestion: - leave "btrfs fi df" as is to no break any script (if any) which would uses it. Hide it from the help and deprecating it in the man page. This because the output is very different. - renaming "btrfs fi disk-usage" in "btrfs fi disk-free", which make sense. 1) btrfs is still labeled experimental, so no script author should have seriously relied on utilities text output to stay unchanged long-term; personally I don't see modifying it (especially not in some superficial way, but as a part of major improvement) to be a problem; 2) "disk-usage" and "disk-free" are both way too awkward and too long to type, compared to "fi df", and "df" is the expected shorthand for "disk free" in the UNIX land. -- With respect, Roman ~~~ "Stallman had a printer, with code he could not see. So he began to tinker, and set the software free." This message was sent using IMP, the Internet Messaging Program. -- To unsubscribe from this list: send the line "unsubscribe linux-btrfs" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RFC] btrfs fi df output [Was Re: BTRF - Storage Usage]
Hi, First of all, i've to say that i'm not a linux specialist, so that means my point of view is balanced between a linux admin and a user. I may also say "stupid" things, so pleas excuse me in advance :p The first difference between the original command and the discussed one is on the value for the DUP parts (one has to be multiplied by 2, whereas the other is already multiplied by 2). I think this should be indicated somewhere in order to avoid confusion. This has been pointed already, but whatever the output is, it is essential to know if the value is raw or not, if it has to be multiplied or divided. Also, i do agree with Hugo concerning the output to make it easier to parse through scripting. The units should also be settable in order to have the same units for all values. Basically, this new output is more explicit for me and remove a bit of confusion. Although, the part "Average_disk_efficiency" seems confusing as i'm not sure the term "efficiency" is correct in that part. That makes me ask some questions : why this much allocated ? when will it allocate more ? how much might be allocated ? ... So, this percentage doesn't indicate an efficient usage of disk space or not ... for me, it indicates that it needed to allocated that (depending on the chunk size). In this example there's indeed 30% of the allocation that is unused, but it will be used as data will grow on the disk. For me it's similar as a LUN created in thick provisioning ... i might not need all the space, but i don't want to be stuck if i'll need it. (dunno if i'm clear on that part) Am i wrong in saying that "Free_(Estimated)" is a false value as the snapshots size isn't included ? Let's say i've like 10 GB of snapshots ... then Free_(Estimated)=Free_(Estimated)-snaps size ? no ? Is it possible to include those snaps size somewhere (maybe not to include in the summary or details, but to add another section or option allowing to have that info) ? Finally, i do agree about the linearly growth as the best model currently. For several reasons, some already explained by Hugo, and because as far as i understood, there is no "single" way to know very accurately how your disk is used. That said, the point is at least to give the most accurate data as possible and to be able to interpret them. In a production environment, i can't afford to say "sorry, the app is crashed because my disk is full". So i need a view on what's happening on my disk. Even if it lacks perfect accuracy, i can place thresholds to avoid any problem (70% of disk full as a warning for example). So, i would change some terms i guess indicating more precisely the "raw" data and the already computed ones. I would also not use the term efficiency as people may wonder at some point if they didn't make a mistake using btrfs seeing a % never near from 100. The "Data_to_disk_ratio" seems preferable for me. Cordialement, Sébastien Goffredo Baroncelli a écrit : On 09/28/2012 10:13 PM, Hugo Mills wrote: Summary: Disk_size: 135.00 GiB Disk_allocated: 10.51 GiB Disk_unallocated: 124.49 GiB Used: 2.59 GiB Free_(Estimated):91.93 GiB Average_disk_efficiency: 70 % Details: Chunk-typeMode Disk-allocated Used Available Data Single4.01GB 2.16GB 1.87GB SystemDUP 16.00MB 4.00KB 7.99MB SystemSingle4.00MB0.00 4.00MB Metadata DUP 6.00GB429.16MB 2.57GB Metadata Single8.00MB0.00 8.00MB Where: Disk-allocated -> space used on the disk by the chunk Disk-size -> size of the disk Disk-unallocated-> disk not used in any chunk Used-> space used by the files/metadata The problem here is that if you're using raw storage, the Used value in the second stanza grows twice as fast as the user expects. This is the misunderstanding whom I talked before. If you give a look at the line "Metadata DUP", you can see that the disk-allocated are about 6GB, instead if you sum Used and Available you got 3GB. I.e. if you create a 1GB file, "Used" ever increased of 1GB, and Available ever decrease 1GB, whichever you are using DUP or Single or RAID* I think this second stanza should at minimum include the "cooked" values used in btrfs fi df, because those reflect the user's experience. Then adding [some of?] the raw values you've got here to help connect the values to the raw data in the first stanza of output. The only raw values are the one "prefixed" with disk. The other ones are at the net of the DUP/Single/Raid As I said above, it's the connection between "I wrote a 1GiB file to my filesystem" and "why have my numbers increased/decreased by 2GiB(*)/1
Re: BTRF - Storage Usage
Hi,
Thanks a lot for your time and answers.
Things look pretty clear now for me.
I'm monitoring my systems using nagios, and i was annoyed about the
disk usage monitoring.
Thanks to your answers, i should be able to developp a rather accurate script.
Or so i hope :)
Regards,
Sebastien.
Hugo Mills a écrit :
On Thu, Sep 27, 2012 at 01:25:58PM +0200, Sébastien Maury wrote:
Hi,
Thanks for the quick reply, this clarify me lots of things.
I've had read the articles you mentioned, but i must admit that your
explanations based on my examples makes things even more clearer.
Also, if i understand things properly, snaphots size aren't included
in the "btrfs filesystem show" command output ?
So, the use, for example, of a "du -sh /.snapshots" is correct to
determine the disk usage of my snapshots ?
"Disk usage of a snapshot" has two different answers:
1) The total size of the files listed in the snapshot, which you can
get from du.
2) The amount of space that would be freed up by deleting the
snapshot, which isn't currently available, but probably will be
soon. (The additional bookkeeping code was part of the qgroups
patches, which are in 3.6).
I will see with the people of my company in charge of maintaining
distributions to provide us a more recent kernel.
PS : I use SLES 11 SP2 distribution.
OK, that one's actually one of the few that does keep proper
backports:
https://btrfs.wiki.kernel.org/index.php/Getting_started#Distro_support
That said, I don't know how good they are at keeping up -- probably
pretty good, but other people here may be able to answer that better.
Hugo.
Hugo Mills a écrit :
> On Thu, Sep 27, 2012 at 12:44:27PM +0200, Sébastien Maury wrote:
>> I've installed a new server using btrfs for my root partition ("/").
>>
>> It uses snapper for snapshots management and all seems to work
pretty fine.
>>
>> My problem is to be able to know the remaining REAL free space in my
>> partition.
>
>This is in the FAQ:
>
https://btrfs.wiki.kernel.org/index.php/FAQ#Why_are_there_so_many_ways_to_check_the_amount_of_free_space.3F
>
>Short answer: you can't know in general.
>
>Longer answer -- see below.
>
>> Using different commands, i have different results, and i don't know
>> how to interpret them correctly :
>
>> poivron:~ # btrfs filesystem show /dev/sda3
>> Label: none uuid: 9e68b667-f9f9-490f-9da1-ae4e91558212
>> Total devices 1 FS bytes used 2.58GB
>> devid1 size 131.64GB used 10.04GB path /dev/sda3
>
>You have 131.64 GiB of raw storage in your filesystem. Of that,
> 10.04 GiB is currently allocated for use by the FS (and it will take
> more as it needs it).
>
>> poivron:~ # btrfs filesystem df /
>> Data: total=4.01GB, used=2.16GB
>
>4.01 GiB of the 10.04 GiB allocation is assigned for use by data,
> and 2.16 GiB of that allocation actually contains data.
>
>> System, DUP: total=8.00MB, used=4.00KB
>
>16 MiB (=2*8.00 MiB) of the 10.04 GiB allocation is assigned for
> use as two copies of the system data. There is 4 KiB of system data
> actually used.
>
>> System: total=4.00MB, used=0.00
>> Metadata, DUP: total=3.00GB, used=429.16MB
>
>6 GiB (=2*3.00 GiB) of your 10.04 GiB allocation is assigned for
> use as metadata, with two copies (DUP) being kept. 429.16 MiB of the
> 3.00 GiB is currently in use.
>
>> Metadata: total=8.00MB, used=0.00
>
>> poivron:~ # df -hP /
>> Filesystem Size Used Avail Use% Mounted on
>> /dev/sda3 132G 3.0G 124G 3% /
>
>Plain old df can't handle the truth, so this is at best only a hint
> at what's actually happening. When "Avail" reaches zero, your FS is
> probably full. Other than that, you can't necessarily say very much.
>
>> ===
>>
>> Please help me understand and interpret those information to know the
>> most accurately as possible what is my real remaining space, and what
>> space is used by what.
>>
>> Although, i don't really understand the output of the command "btrfs
>> filesystem df /" : what are exactly "Data", "System DUP", "System
>> total", "Metadata DUP" and "Metadata total" ?
>
>This should all be covered in the glossary on the website:
> https://btrfs.wiki.kernel.org/index.php/Glossary
>
>Data is the contents of your files. Metadata is all the other stuff
> that the FS needs in order to store your files -- directory
> structures, permissions, locations of the file data, that kind of
> thing. System is a particular bit of the metadata (
Re: BTRF - Storage Usage
Hi,
Thanks for the quick reply, this clarify me lots of things.
I've had read the articles you mentioned, but i must admit that your
explanations based on my examples makes things even more clearer.
Also, if i understand things properly, snaphots size aren't included
in the "btrfs filesystem show" command output ?
So, the use, for example, of a "du -sh /.snapshots" is correct to
determine the disk usage of my snapshots ?
I will see with the people of my company in charge of maintaining
distributions to provide us a more recent kernel.
PS : I use SLES 11 SP2 distribution.
Hugo Mills a écrit :
On Thu, Sep 27, 2012 at 12:44:27PM +0200, Sébastien Maury wrote:
I've installed a new server using btrfs for my root partition ("/").
It uses snapper for snapshots management and all seems to work pretty fine.
My problem is to be able to know the remaining REAL free space in my
partition.
This is in the FAQ:
https://btrfs.wiki.kernel.org/index.php/FAQ#Why_are_there_so_many_ways_to_check_the_amount_of_free_space.3F
Short answer: you can't know in general.
Longer answer -- see below.
Using different commands, i have different results, and i don't know
how to interpret them correctly :
poivron:~ # btrfs filesystem show /dev/sda3
Label: none uuid: 9e68b667-f9f9-490f-9da1-ae4e91558212
Total devices 1 FS bytes used 2.58GB
devid1 size 131.64GB used 10.04GB path /dev/sda3
You have 131.64 GiB of raw storage in your filesystem. Of that,
10.04 GiB is currently allocated for use by the FS (and it will take
more as it needs it).
poivron:~ # btrfs filesystem df /
Data: total=4.01GB, used=2.16GB
4.01 GiB of the 10.04 GiB allocation is assigned for use by data,
and 2.16 GiB of that allocation actually contains data.
System, DUP: total=8.00MB, used=4.00KB
16 MiB (=2*8.00 MiB) of the 10.04 GiB allocation is assigned for
use as two copies of the system data. There is 4 KiB of system data
actually used.
System: total=4.00MB, used=0.00
Metadata, DUP: total=3.00GB, used=429.16MB
6 GiB (=2*3.00 GiB) of your 10.04 GiB allocation is assigned for
use as metadata, with two copies (DUP) being kept. 429.16 MiB of the
3.00 GiB is currently in use.
Metadata: total=8.00MB, used=0.00
poivron:~ # df -hP /
Filesystem Size Used Avail Use% Mounted on
/dev/sda3 132G 3.0G 124G 3% /
Plain old df can't handle the truth, so this is at best only a hint
at what's actually happening. When "Avail" reaches zero, your FS is
probably full. Other than that, you can't necessarily say very much.
===
Please help me understand and interpret those information to know the
most accurately as possible what is my real remaining space, and what
space is used by what.
Although, i don't really understand the output of the command "btrfs
filesystem df /" : what are exactly "Data", "System DUP", "System
total", "Metadata DUP" and "Metadata total" ?
This should all be covered in the glossary on the website:
https://btrfs.wiki.kernel.org/index.php/Glossary
Data is the contents of your files. Metadata is all the other stuff
that the FS needs in order to store your files -- directory
structures, permissions, locations of the file data, that kind of
thing. System is a particular bit of the metadata (the chunk tree)
which governs an internal physical/virtual mapping, and which needs to
be read before anything else can make any kind of sense.
DUP is a bit like RAID-1: anything stored in a DUP chunk is
actually written to two different places on the disk, and can help
recovery in the case of physical disk corruption (e.g. bad blocks,
head crash).
==
Here are some complementary informations :
poivron:~ # uname -a
Linux poivron 3.0.26-0.7-default #1 SMP Tue Apr 17 10:27:57 UTC 2012
(3829766) x86_64 x86_64 x86_64 GNU/Linux
You [probably(*)] need to upgrade your kernel as soon as possible.
btrfs code moves very fast, and 3.0 has significant bugs in it. You
should be running the latest released kernel -- right now, that's 3.5,
or 3.6-rc7. Next week, it will probably change to 3.6 when Linus makes
the next release. Most distributions have a repository somewhere which
will give you access to new kernels without too much trouble.
Hugo.
(*) Some of the enterprise distributions do have backported btrfs
fixes in their apparently older kernels.
--
=== Hugo Mills: hugo@... carfax.org.uk | darksatanic.net | lug.org.uk ===
PGP key: 515C238D from wwwkeys.eu.pgp.net or http://www.carfax.org.uk
--- __(_'> Squeak! ---
Cordialement,
Sébastien MAURY
Responsable d'exploitation du site de Montpellier
Équipe DBA
___
INSERM - DSI - Pôle Infrastructures
Délégation régionale La
BTRF - Storage Usage
Hi,
I've installed a new server using btrfs for my root partition ("/").
It uses snapper for snapshots management and all seems to work pretty fine.
My problem is to be able to know the remaining REAL free space in my
partition.
Using different commands, i have different results, and i don't know
how to interpret them correctly :
poivron:~ # btrfs filesystem df /
Data: total=4.01GB, used=2.16GB
System, DUP: total=8.00MB, used=4.00KB
System: total=4.00MB, used=0.00
Metadata, DUP: total=3.00GB, used=429.16MB
Metadata: total=8.00MB, used=0.00
poivron:~ # df -hP /
Filesystem Size Used Avail Use% Mounted on
/dev/sda3 132G 3.0G 124G 3% /
poivron:~ # btrfs filesystem show /dev/sda3
Label: none uuid: 9e68b667-f9f9-490f-9da1-ae4e91558212
Total devices 1 FS bytes used 2.58GB
devid1 size 131.64GB used 10.04GB path /dev/sda3
Btrfs v0.19+
poivron:~ # du -sh /.snapshots
40G /.snapshots
===
Please help me understand and interpret those information to know the
most accurately as possible what is my real remaining space, and what
space is used by what.
Although, i don't really understand the output of the command "btrfs
filesystem df /" : what are exactly "Data", "System DUP", "System
total", "Metadata DUP" and "Metadata total" ?
==
Here are some complementary informations :
poivron:~ # uname -a
Linux poivron 3.0.26-0.7-default #1 SMP Tue Apr 17 10:27:57 UTC 2012
(3829766) x86_64 x86_64 x86_64 GNU/Linux
poivron:~ # snapper list-configs
Config| Subvolume
--+
root | /
poivron:~ # cat /etc/snapper/configs/root
# subvolume to snapshot
SUBVOLUME="/"
# filesystem type
FSTYPE="btrfs"
# run daily number cleanup
NUMBER_CLEANUP="yes"
# limit for number cleanup
NUMBER_MIN_AGE="1800"
NUMBER_LIMIT="100"
# create hourly snapshots
TIMELINE_CREATE="yes"
# cleanup hourly snapshots after some time
TIMELINE_CLEANUP="yes"
# limits for timeline cleanup
TIMELINE_MIN_AGE="1800"
TIMELINE_LIMIT_HOURLY="10"
TIMELINE_LIMIT_DAILY="10"
TIMELINE_LIMIT_MONTHLY="10"
TIMELINE_LIMIT_YEARLY="10"
# cleanup empty pre-post-pairs
EMPTY_PRE_POST_CLEANUP="yes"
# limits for empty pre-post-pair cleanup
EMPTY_PRE_POST_MIN_AGE="1800"
Cordialement,
Sébastien MAURY
Responsable d'exploitation du site de Montpellier
Équipe DBA
___
INSERM - DSI - Pôle Infrastructures
Délégation régionale Languedoc Roussillon
60, rue de Navacelles
34394 Montpellier Cedex 5
Mob : 06 31 51 42 18
Fixe : 04 67 63 61 43
Fax : 04 67 63 70 25
Mél : sebastien.ma...@inserm.fr
___
This message was sent using IMP, the Internet Messaging Program.
--
To unsubscribe from this list: send the line "unsubscribe linux-btrfs" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
