Re: 4.4.0 - no space left with >1.7 TB free space left
On Fri, 8 Apr 2016 16:53:32 +0500 Roman Mamedov wrote: > On Fri, 08 Apr 2016 20:36:26 +0900 > Tomasz Chmielewski wrote: > > > On 2016-02-08 20:24, Roman Mamedov wrote: > > > > >> Linux 4.4.0 - btrfs is mainly used to host lots of test containers, > > >> often snapshots, and at times, there is heavy IO in many of them for > > >> extended periods of time. btrfs is on HDDs. > > >> > > >> > > >> Every few days I'm getting "no space left" in a container running > > >> mongo > > >> 3.2.1 database. Interestingly, haven't seen this issue in containers > > >> with MySQL. All databases have chattr +C set on their directories. > > > > > > Hello, > > > > > > Do you snapshot the parent subvolume which holds the databases? Can you > > > correlate that perhaps ENOSPC occurs at the time of snapshotting? If > > > yes, then > > > you should try the patch https://patchwork.kernel.org/patch/7967161/ > > > > > > (Too bad this was not included into 4.4.1.) > > > > By the way - was it included in any later kernel? I'm running 4.4.5 on > > that server, but still hitting the same issue. > > It's not in 4.4.6 either. I don't know why it doesn't get included, or what > we need to do. Last time I asked, it was queued: > http://www.spinics.net/lists/linux-btrfs/msg52478.html > But maybe that meant 4.5 or 4.6 only? While the bug is affecting people on > 4.4.x today. This got applied now in 4.4.21, thanks. -- With respect, Roman pgpqOFdEk406P.pgp Description: OpenPGP digital signature
Re: 4.4.0 - no space left with >1.7 TB free space left
On 2016-05-12 15:03, Tomasz Chmielewski wrote:
FYI, I'm still getting this with 4.5.3, which probably means the fix
was not yet included ("No space left" at snapshot time):
/var/log/postgresql/postgresql-9.3-main.log:2016-05-11 06:06:10 UTC
LOG: could not close temporary statistics file
"pg_stat_tmp/db_0.tmp": No space left on device
/var/log/postgresql/postgresql-9.3-main.log:2016-05-11 06:06:10 UTC
LOG: could not close temporary statistics file
"pg_stat_tmp/global.tmp": No space left on device
/var/log/postgresql/postgresql-9.3-main.log:2016-05-11 06:06:10 UTC
LOG: could not close temporary statistics file
"pg_stat_tmp/db_0.tmp": No space left on device
/var/log/postgresql/postgresql-9.3-main.log:2016-05-11 06:06:10 UTC
LOG: could not close temporary statistics file
"pg_stat_tmp/global.tmp": No space left on device
I've tried mounting with space_cache=v2, but it didn't help.
On the good side, I see it's in 4.6-rc7.
Tomasz Chmielewski
http://wpkg.org
--
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: 4.4.0 - no space left with >1.7 TB free space left
On 2016-04-08 20:53, Roman Mamedov wrote:
> Do you snapshot the parent subvolume which holds the databases? Can you
> correlate that perhaps ENOSPC occurs at the time of snapshotting? If
> yes, then
> you should try the patch https://patchwork.kernel.org/patch/7967161/
>
> (Too bad this was not included into 4.4.1.)
By the way - was it included in any later kernel? I'm running 4.4.5 on
that server, but still hitting the same issue.
It's not in 4.4.6 either. I don't know why it doesn't get included, or
what
we need to do. Last time I asked, it was queued:
http://www.spinics.net/lists/linux-btrfs/msg52478.html
But maybe that meant 4.5 or 4.6 only? While the bug is affecting people
on
4.4.x today.
FYI, I'm still getting this with 4.5.3, which probably means the fix was
not yet included ("No space left" at snapshot time):
/var/log/postgresql/postgresql-9.3-main.log:2016-05-11 06:06:10 UTC LOG:
could not close temporary statistics file "pg_stat_tmp/db_0.tmp": No
space left on device
/var/log/postgresql/postgresql-9.3-main.log:2016-05-11 06:06:10 UTC LOG:
could not close temporary statistics file "pg_stat_tmp/global.tmp": No
space left on device
/var/log/postgresql/postgresql-9.3-main.log:2016-05-11 06:06:10 UTC LOG:
could not close temporary statistics file "pg_stat_tmp/db_0.tmp": No
space left on device
/var/log/postgresql/postgresql-9.3-main.log:2016-05-11 06:06:10 UTC LOG:
could not close temporary statistics file "pg_stat_tmp/global.tmp": No
space left on device
I've tried mounting with space_cache=v2, but it didn't help.
Tomasz Chmielewski
http://wpkg.org
--
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: 4.4.0 - no space left with >1.7 TB free space left
Roman Mamedov posted on Fri, 08 Apr 2016 16:53:32 +0500 as excerpted: > It's not in 4.4.6 either. I don't know why it doesn't get included, or > what we need to do. Last time I asked, it was queued: > http://www.spinics.net/lists/linux-btrfs/msg52478.html But maybe that > meant 4.5 or 4.6 only? While the bug is affecting people on 4.4.x today. Patches must make it to the current development kernel before they're eligible for stable. Additionally, they need to be cced to stable as well, in ordered to be queued there. So check 4.5 and 4.6-rc. If it's in neither of those, it's not going to be in stable yet. Once it's in the development kernel, see if it was cced to stable and if needed, ask the author and btrfs devs to cc it to stable. Tho sometimes stable can get a backlog as well. I know earlier this year they were dealing with one, but I follow release or development, not stable, and don't know what stable's current status is. If it gets to stable, and it wasn't for a bug introduced /after/ 4.4, it should eventually get into 4.4, as that's an LTS kernel. But it might take awhile, as the above discussion hints. -- 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 -- 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: 4.4.0 - no space left with >1.7 TB free space left
On 2016-04-08 20:53, Roman Mamedov wrote: > Do you snapshot the parent subvolume which holds the databases? Can you > correlate that perhaps ENOSPC occurs at the time of snapshotting? If > yes, then > you should try the patch https://patchwork.kernel.org/patch/7967161/ > > (Too bad this was not included into 4.4.1.) By the way - was it included in any later kernel? I'm running 4.4.5 on that server, but still hitting the same issue. It's not in 4.4.6 either. I don't know why it doesn't get included, or what we need to do. Last time I asked, it was queued: http://www.spinics.net/lists/linux-btrfs/msg52478.html But maybe that meant 4.5 or 4.6 only? While the bug is affecting people on 4.4.x today. Does it mean 4.5 also doesn't have it yet? Tomasz Chmielewski http://wpkg.org -- 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: 4.4.0 - no space left with >1.7 TB free space left
On Fri, 08 Apr 2016 20:36:26 +0900 Tomasz Chmielewski wrote: > On 2016-02-08 20:24, Roman Mamedov wrote: > > >> Linux 4.4.0 - btrfs is mainly used to host lots of test containers, > >> often snapshots, and at times, there is heavy IO in many of them for > >> extended periods of time. btrfs is on HDDs. > >> > >> > >> Every few days I'm getting "no space left" in a container running > >> mongo > >> 3.2.1 database. Interestingly, haven't seen this issue in containers > >> with MySQL. All databases have chattr +C set on their directories. > > > > Hello, > > > > Do you snapshot the parent subvolume which holds the databases? Can you > > correlate that perhaps ENOSPC occurs at the time of snapshotting? If > > yes, then > > you should try the patch https://patchwork.kernel.org/patch/7967161/ > > > > (Too bad this was not included into 4.4.1.) > > By the way - was it included in any later kernel? I'm running 4.4.5 on > that server, but still hitting the same issue. It's not in 4.4.6 either. I don't know why it doesn't get included, or what we need to do. Last time I asked, it was queued: http://www.spinics.net/lists/linux-btrfs/msg52478.html But maybe that meant 4.5 or 4.6 only? While the bug is affecting people on 4.4.x today. Thanks -- With respect, Roman pgpxDETSxWzY9.pgp Description: OpenPGP digital signature
Re: 4.4.0 - no space left with >1.7 TB free space left
On 2016-02-08 20:24, Roman Mamedov wrote: Linux 4.4.0 - btrfs is mainly used to host lots of test containers, often snapshots, and at times, there is heavy IO in many of them for extended periods of time. btrfs is on HDDs. Every few days I'm getting "no space left" in a container running mongo 3.2.1 database. Interestingly, haven't seen this issue in containers with MySQL. All databases have chattr +C set on their directories. Hello, Do you snapshot the parent subvolume which holds the databases? Can you correlate that perhaps ENOSPC occurs at the time of snapshotting? If yes, then you should try the patch https://patchwork.kernel.org/patch/7967161/ (Too bad this was not included into 4.4.1.) By the way - was it included in any later kernel? I'm running 4.4.5 on that server, but still hitting the same issue. Tomasz Chmielewski http://wpkg.org -- 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: 4.4.0 - no space left with >1.7 TB free space left
On Mon, 08 Feb 2016 21:15:38 +0900 Tomasz Chmielewski wrote: > With the last error, a snapshot was made at around 06:06 > "no space left" was reported on 06:14. If you mean the log that you have posted in your original message, the ENOSPC happened at 06:06 and 14 seconds, not 06:14. -- With respect, Roman pgpGvudF_ZoCz.pgp Description: OpenPGP digital signature
Re: 4.4.0 - no space left with >1.7 TB free space left
On 2016-02-08 20:24, Roman Mamedov wrote: On Mon, 08 Feb 2016 18:22:34 +0900 Tomasz Chmielewski wrote: Linux 4.4.0 - btrfs is mainly used to host lots of test containers, often snapshots, and at times, there is heavy IO in many of them for extended periods of time. btrfs is on HDDs. Every few days I'm getting "no space left" in a container running mongo 3.2.1 database. Interestingly, haven't seen this issue in containers with MySQL. All databases have chattr +C set on their directories. Hello, Do you snapshot the parent subvolume which holds the databases? Can you correlate that perhaps ENOSPC occurs at the time of snapshotting? Not sure. With the last error, a snapshot was made at around 06:06, while "no space left" was reported on 06:14. Suspiciously close to each other, but still, a few minutes away. Unfortunately I don't have error log for previous cases. If yes, then you should try the patch https://patchwork.kernel.org/patch/7967161/ (Too bad this was not included into 4.4.1.) I'll keep an eye on it, thanks. Tomasz Chmielewski http://www.ptraveler.com -- 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: 4.4.0 - no space left with >1.7 TB free space left
On Mon, 08 Feb 2016 18:22:34 +0900 Tomasz Chmielewski wrote: > Linux 4.4.0 - btrfs is mainly used to host lots of test containers, > often snapshots, and at times, there is heavy IO in many of them for > extended periods of time. btrfs is on HDDs. > > > Every few days I'm getting "no space left" in a container running mongo > 3.2.1 database. Interestingly, haven't seen this issue in containers > with MySQL. All databases have chattr +C set on their directories. Hello, Do you snapshot the parent subvolume which holds the databases? Can you correlate that perhaps ENOSPC occurs at the time of snapshotting? If yes, then you should try the patch https://patchwork.kernel.org/patch/7967161/ (Too bad this was not included into 4.4.1.) -- With respect, Roman pgpQUIIInnFRo.pgp Description: OpenPGP digital signature
4.4.0 - no space left with >1.7 TB free space left
Linux 4.4.0 - btrfs is mainly used to host lots of test containers, often snapshots, and at times, there is heavy IO in many of them for extended periods of time. btrfs is on HDDs. Every few days I'm getting "no space left" in a container running mongo 3.2.1 database. Interestingly, haven't seen this issue in containers with MySQL. All databases have chattr +C set on their directories. Why would it fail, if there is so much space left? 2016-02-07T06:06:14.648+ E STORAGE [thread1] WiredTiger (28) [1454825174:633585][9105:0x7f2b7e33e700], file:collection-33-7895599108848542105.wt, WT_SESSION.checkpoint: collection-33-7895599108848542105.wt write error: failed to write 4096 bytes at offset 20480: No space left on device 2016-02-07T06:06:14.648+ E STORAGE [thread1] WiredTiger (28) [1454825174:648740][9105:0x7f2b7e33e700], checkpoint-server: checkpoint server error: No space left on device 2016-02-07T06:06:14.648+ E STORAGE [thread1] WiredTiger (-31804) [1454825174:648766][9105:0x7f2b7e33e700], checkpoint-server: the process must exit and restart: WT_PANIC: WiredTiger library panic 2016-02-07T06:06:14.648+ I -[thread1] Fatal Assertion 28558 2016-02-07T06:06:14.648+ I -[thread1] ***aborting after fassert() failure 2016-02-07T06:06:14.694+ I -[WTJournalFlusher] Fatal Assertion 28559 2016-02-07T06:06:14.694+ I -[WTJournalFlusher] ***aborting after fassert() failure 2016-02-07T06:06:15.203+ F -[WTJournalFlusher] Got signal: 6 (Aborted). # df -h /srv Filesystem Size Used Avail Use% Mounted on /dev/sda4 2.7T 1.1T 1.7T 39% /srv # btrfs fi df /srv Data, RAID1: total=1.25TiB, used=1014.01GiB System, RAID1: total=32.00MiB, used=240.00KiB Metadata, RAID1: total=15.00GiB, used=13.13GiB GlobalReserve, single: total=512.00MiB, used=0.00B # btrfs fi show /srv Label: 'btrfs' uuid: 105b2e0c-8af2-45ee-b4c8-14ff0a3ca899 Total devices 2 FS bytes used 1.00TiB devid1 size 2.63TiB used 1.26TiB path /dev/sda4 devid2 size 2.63TiB used 1.26TiB path /dev/sdb4 btrfs-progs v4.0.1 Tomasz Chmielewski http://wpkg.org -- 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: Free space left
Hello, kreij...@gmail.com (Goffredo Baroncelli) writes: > Try btrfs-show > [...] How do you read this then: Label: none uuid: 27fafa43-7ad0-4e8a-ada8-36f73ef8984c Total devices 2 FS bytes used 79.63GB devid2 size 111.79GB used 111.01GB path /dev/sdb devid1 size 111.79GB used 111.03GB path /dev/sda I'm pretty sure I created this fs with -d raid1 -m raid1! Speaking of which, is there a way to read a FS configuration: how can I tell this FS really uses raid1 for both data and metadata? The used column is surprising: if it's a mirror why 111.01 and 111.03? And why all the space is being used anyway: I mean what's the difference between the 79.63GB and 111.0[13]? And the output of df is confusing too: /dev/sdb 234441648 83501968 150939680 36% /space It's reporting twice the total space but I think I remember looking it up and that should be fixed in a future kernel version. -- Mathieu Chouquet-Stringer mchou...@free.fr The sun itself sees not till heaven clears. -- William Shakespeare -- -- 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: Free space left
On Saturday 16 January 2010, Mathieu Chouquet-Stringer wrote: > Hello, > > kreij...@gmail.com (Goffredo Baroncelli) writes: > > Try btrfs-show > > [...] > > How do you read this then: > > Label: none uuid: 27fafa43-7ad0-4e8a-ada8-36f73ef8984c > Total devices 2 FS bytes used 79.63GB > devid2 size 111.79GB used 111.01GB path /dev/sdb > devid1 size 111.79GB used 111.03GB path /dev/sda > > I'm pretty sure I created this fs with -d raid1 -m raid1! Speaking > of which, is there a way to read a FS configuration: how can I tell > this FS really uses raid1 for both data and metadata? Even tough the raid mode is set per filesystem, btrfs has (will have) the capability to set the raid level per file. So it is no simple to estimate the free space: if every file is raid1 the real free space is half of the physical free space. But if some file are in raid1 (for examples /etc) and others are in raid0 (for example the ones under /usr which may be re-downloaded) the used space and the free space are difficult to estimate. There are some efforts to fix this kind of situation (see the thread "[PATCH] Btrfs-progs: add btrfsctl -i to print space info"). > The used column is surprising: if it's a mirror why 111.01 and > 111.03? And why all the space is being used anyway: I mean what's > the difference between the 79.63GB and 111.0[13]? > > And the output of df is confusing too: > /dev/sdb 234441648 83501968 150939680 36% /space > > It's reporting twice the total space but I think I remember looking > it up and that should be fixed in a future kernel version. > -- > Mathieu Chouquet-Stringer mchou...@free.fr > The sun itself sees not till heaven clears. >-- William Shakespeare -- > -- gpg key@ keyserver.linux.it: Goffredo Baroncelli (ghigo) Key fingerprint = 4769 7E51 5293 D36C 814E C054 BF04 F161 3DC5 0512 -- 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: Free space left
On Saturday 16 January 2010, you (Svein Erik Brostigen) wrote: > Goffredo Baroncelli wrote: > > Try btrfs-show > > > Ok: > $ mount > /dev/sdc on /media/452f782b-738a-4699-abfa-588eecab07ea type btrfs > (rw,nosuid,nodev,uhelper=devkit) > > $ df > /dev/sdc 932G 6.7G 925G 1% > /media/452f782b-738a-4699-abfa-588eecab07ea > > $ btrfs-show > failed to read /dev/sdb1 > failed to read /dev/sdc ^ It seems that you don't have the right to read /dev/sdc. Retry as super user. [...] > Btrfs Btrfs v0.19 > > The drive used is a Seagate FreeAgent 1Tb USB drive under Ubuntu 9.10 > > $ uname -a > Linux ebrostig-laptop 2.6.31-18-generic-pae #55-Ubuntu SMP Fri Jan 8 > 16:13:23 UTC 2010 i686 GNU/Linux > > Erik > > -- gpg key@ keyserver.linux.it: Goffredo Baroncelli (ghigo) Key fingerprint = 4769 7E51 5293 D36C 814E C054 BF04 F161 3DC5 0512 -- 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: Free space left
Goffredo Baroncelli wrote: Try btrfs-show Ok: $ mount /dev/sdc on /media/452f782b-738a-4699-abfa-588eecab07ea type btrfs (rw,nosuid,nodev,uhelper=devkit) $ df /dev/sdc 932G 6.7G 925G 1% /media/452f782b-738a-4699-abfa-588eecab07ea $ btrfs-show failed to read /dev/sdb1 failed to read /dev/sdc failed to read /dev/sdb failed to read /dev/sda5 failed to read /dev/sda1 failed to read /dev/sda6 failed to read /dev/sda2 failed to read /dev/sda failed to read /dev/sr0 failed to read /dev/loop1 failed to read /dev/ram2 failed to read /dev/ram10 failed to read /dev/ram11 failed to read /dev/loop7 failed to read /dev/ram1 failed to read /dev/loop0 failed to read /dev/loop5 failed to read /dev/loop2 failed to read /dev/loop3 failed to read /dev/loop4 failed to read /dev/loop6 failed to read /dev/ram12 failed to read /dev/ram4 failed to read /dev/ram13 failed to read /dev/ram5 failed to read /dev/ram8 failed to read /dev/ram14 failed to read /dev/ram15 failed to read /dev/ram0 failed to read /dev/ram3 failed to read /dev/ram6 failed to read /dev/ram9 failed to read /dev/ram7 Btrfs Btrfs v0.19 The drive used is a Seagate FreeAgent 1Tb USB drive under Ubuntu 9.10 $ uname -a Linux ebrostig-laptop 2.6.31-18-generic-pae #55-Ubuntu SMP Fri Jan 8 16:13:23 UTC 2010 i686 GNU/Linux Erik -- 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: Free space left
On Saturday 16 January 2010, you (Dipl.-Ing. Michael Niederle) wrote: > Hi, Goffredo! > > > Try btrfs-show > > Thanks for your advice! > > btrfs-show works but it displays a lot of error message for non-btrfs devices: > > > btrfs-show > failed to read /dev/sdg > failed to read /dev/sdg1 > failed to read /dev/sdg2 > failed to read /dev/sdg3 > failed to read /dev/sdg4 > failed to read /dev/md1 > failed to read /dev/fd0 > failed to read /dev/fd0u1440 > failed to read /dev/fd1 > failed to read /dev/hda > failed to read /dev/hda1 > failed to read /dev/hda10 > failed to read /dev/hda11 > failed to read /dev/hda12 > ... > failed to read /dev/sr0 > failed to read /dev/sr1 > failed to read /dev/sr2 > failed to read /dev/sr3 > ... > Label: Alpha4 uuid: 63b82dad-ed81-41f4-910f-7b358ceb77ba > Total devices 1 FS bytes used 11.81GB > devid1 size 20.01GB used 20.01GB path /dev/sda3 > > Btrfs v0.19-4-gab8fb4c > > Even if I try > > btrfs-show /dev/sda3 > > I get the same output. > > Greetings, Michael > Yes they search in every block devices a btrfs file-system. It may be smarter/faster skipping the floppy and the cd-rom.. BR G.Baroncelli -- gpg key@ keyserver.linux.it: Goffredo Baroncelli (ghigo) Key fingerprint = 4769 7E51 5293 D36C 814E C054 BF04 F161 3DC5 0512 -- 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: Free space left
Hi, Goffredo! > Try btrfs-show Thanks for your advice! btrfs-show works but it displays a lot of error message for non-btrfs devices: > btrfs-show failed to read /dev/sdg failed to read /dev/sdg1 failed to read /dev/sdg2 failed to read /dev/sdg3 failed to read /dev/sdg4 failed to read /dev/md1 failed to read /dev/fd0 failed to read /dev/fd0u1440 failed to read /dev/fd1 failed to read /dev/hda failed to read /dev/hda1 failed to read /dev/hda10 failed to read /dev/hda11 failed to read /dev/hda12 ... failed to read /dev/sr0 failed to read /dev/sr1 failed to read /dev/sr2 failed to read /dev/sr3 ... Label: Alpha4 uuid: 63b82dad-ed81-41f4-910f-7b358ceb77ba Total devices 1 FS bytes used 11.81GB devid1 size 20.01GB used 20.01GB path /dev/sda3 Btrfs v0.19-4-gab8fb4c Even if I try btrfs-show /dev/sda3 I get the same output. Greetings, Michael -- 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: Free space left
On Saturday 16 January 2010, Michael Niederle wrote: > How can I detect how much free space is left on a btrfs-volume? > > As I read (and learned in practice!) "df" reports cannot be trusted if used on > btrfs-volumes. Try btrfs-show $ btrfs-show Label: bar uuid: ec2918cd-ad47-4eac-9e85-5604b02fd922 Total devices 1 FS bytes used 302.25MB devid1 size 964.81MB used 614.50MB path /dev/sdc1 Label: debian-root uuid: 6e2a647f-5da2-4bd0-a7d7-9b13d13a47cc Total devices 1 FS bytes used 23.52GB devid1 size 232.11GB used 118.03GB path /dev/sdc3 Btrfs Btrfs v0.19 BR G.Baroncelli -- gpg key@ keyserver.linux.it: Goffredo Baroncelli (ghigo) Key fingerprint = 4769 7E51 5293 D36C 814E C054 BF04 F161 3DC5 0512 -- 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
Free space left
How can I detect how much free space is left on a btrfs-volume? As I read (and learned in practice!) "df" reports cannot be trusted if used on btrfs-volumes. Greetings, Michael -- 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
