btrfs on openSUSE not releasing disk space

I have an openSUSE 12.1 install on my main desktop running with btrfs filesystem for root (/boot is ext4). I started having issues today with KDE informing me that disk space is almost all gone and eventually it decided it was gone and crashed my desktop.

I used Alt+F1 to switch to a terminal screen and although I was sure I was no where near the 1TB limit of my hard disk I moved some 150/200GB of music and video files onto an external drive and rebooted. Didn’t help, same problem, same crash.

Once more I switched to a terminal screen and used du to confirm that I had indeed only used about half of my total diskspace but df (including the btrfs-progs version) insists I have used 100% of available diskspace and so my desktop crashes each and every time I log in.

Using the btrfs defrag utility doesn’t help either. As such I am at a bit of a loss as to where to go next.

(Note I posted this on unix.stackexchange.com but that doesn’t seem to have done much good…)

Btrfs is still unstable and I would not use it on a production system. That said. don’t tell use what a program says show use… it could be you have free space but you have run out of sectors. ie you have lots of small files. Also even if the drive is 1 TB what about the partitions? Show use fdisk -l as well.

On 2012-07-17 14:56, kemra102 wrote:
>
> I have an openSUSE 12.1 install on my main desktop running with btrfs
> filesystem for root (/boot is ext4). I started having issues today with
> KDE informing me that disk space is almost all gone and eventually it
> decided it was gone and crashed my desktop.

It is not root which is full, but /home.

> I used Alt+F1 to switch to a terminal screen and although I was sure
> I was no where near the 1TB limit of my hard disk I moved some
> 150/200GB of music and video files onto an external drive and rebooted.
> Didn’t help, same problem, same crash.

btrfs does not delete files, it keeps all history. You have to compact it, release the history

  • however the operation is called, don’t ask me.


Cheers / Saludos,

Carlos E. R.
(from 11.4 x86_64 “Celadon” at Telcontar)

Read that about what free space on btrfs really means
http://tinyurl.com/3p75tpk
http://tinyurl.com/6779xju


PC: oS 12.1 x86_64 | i7-2600@3.40GHz | 16GB | KDE 4.8.4 | GeForce GT 420
ThinkPad E320: oS 12.1 x86_64 | i3@2.30GHz | 8GB | KDE 4.8.4 | HD 3000
eCAFE 800: oS 12.1 i586 | AMD Geode LX 800@500MHz | 512MB | KDE 3.5.10

Thanks for all your help everyone, I did read everything that was linked etc but in the end I couldn’t even boot into single user mode (not sure what went wrong) so had to re-install in this instance.

I really like NTFS for data volumes because if its ability to compress my huge datafiles (from computational fluid dynamics, etc.). With these types of files, compression makes a huge difference on the number if physical hard drives I have to maintain - big text files are massively compressible - can make a 2TB HD effectively a 4TB HD. I think modern data+metadata-storage files like NetCDF and HDF5 are also highly compressible.

Hence my interest in BtrFS - at least for data volumes. Is Butterfs really so unstable as to make NTFS preferable? I notice it’s now in 12.2 YaST as a seemingly viable option (12.1 x64 SATA3 Phenom x6 4GHz 16GB). I still keep “/” and “/home” as EXT4, just to be safe but I’m particularly concerned about reports that it doesn’t free-up drive space intelligently…:\

I have never had any trouble with NTFS as data drives on my systems (eSATA data drives, mostly), and it’s nice having them portable to M$. But I notice some negative words about NTFS on the internet (server crashes), as well as the suggestion M$ will abandon it in not too many years. None of the other “mainstream” file system options (except maybe Reiser4) seem to offer compression.
Comparison of file systems - Wikipedia, the free encyclopedia

TYIA for any guidance,
Patti

On 2012-12-26 18:46, PattiMichelle wrote:
>
> I really like NTFS for data volumes because if its ability to compress
> my huge datafiles (from computational fluid dynamics, etc.). With these
> types of files, compression makes a huge difference on the number if
> physical hard drives I have to maintain - big text files are massively
> compressible - can make a 2TB HD effectively a 4TB HD. I think modern
> data+metadata-storage files like NetCDF and HDF5 are also highly
> compressible.

Yes, but is that feature available in Linux? AFAIK, no.

At least ext3 offered compression as a possibility, there is a flag for
it. But it has never been implemented, because the developers apparently
think that disk space is ample and cheap. A shame.

> Hence my interest in BtrFS - at least for data volumes. Is Butterfs
> really so unstable as to make NTFS preferable?

Some say it is stable, but I do not trust it yet. Some people have lost
whole partitions, the recovery tools are not finished.

Does it have compression? I’m not aware of it. However, the main feature
of btrfs is that it doesn’t really delete files, these are kept as
historic data, so that you can go back in time and retrieve those old,
deleted files, or go back in time the whole partition. That is, you
could have several versions of the same data, which negates compression
completely.

> I have never had any trouble with NTFS as data drives on my systems
> (eSATA data drives, mostly), and it’s nice having them portable to M$.
> But I notice some negative words about NTFS on the internet (server
> crashes), as well as the suggestion M$ will abandon it in not too many
> years. None of the other “mainstream” file system options (except maybe
> Reiser4) seem to offer compression.

Well, I have seen some hard to recover NTFS crashes, requiring
commercial software to recover data. But I have also seen very bad
crashes in ext3, xfs, and reiserfs, all of them. I don’t know if ntfs is
safer or worse than others. Windows Sserver 2008 is considered pretty
stable, though. And about how many years is Microsoft going to provide
it, I think several years at least (as long as Windows 8 is supported, I
suppose, as a minimum).

And reiserfs4 I have not tried it.

Consider how long a fs is maintained in Linux by looking at the reiserfs
case… It is a wonderful fs, but current devs are not very interested
in it, thus it is being slowly deprecated.


Cheers / Saludos,

Carlos E. R.
(from 11.4, with Evergreen, x86_64 “Celadon” (Minas Tirith))

Hi Robin: Thanks for the discussion. I will have to look into this some more. I don’t know if an NTFS folder with compression enabled (when it’s mounted on windows) will get files written as compressed when the drive is then mounted to Linux - I’ll have to try that - but I think not - it’s a file attribute thing. Even if not, you can always occasionally move the drive and mount it (via eSATA) on windows and compress files to free up space. I have never had a windows’ compressed file fail to be read (under Linux) after it was compressed by windows on NTFS. But I guess I should run the experiment rather than just assuming I know what’s going on because I share drives between linux and windows freely (with compression enabled on NTFS and files compressed).
Happy Holidays!!
Patti

Hmpfhh&#*?!!

Didn’t you try to boot from a live CD ?

To have an alternative Linux system to boot from, anyway seems to be a good idea.

And, you should try it out before needing to use it.

One of the systems I have is an old Pentium III PC,
on which openSUSE 12.1 installs fine from the DVD,
but which on the other hand won’t boot from the 12.1 live CD !

Good luck
Mike

On 2012-12-27 00:26, PattiMichelle wrote:
>
> Hi Robin: Thanks for the discussion. I will have to look into this
> some more. I don’t know if an NTFS folder with compression enabled
> (when it’s mounted on windows) will get files written as compressed when
> the drive is then mounted to Linux - I’ll have to try that - but I think
> not - it’s a file attribute thing. Even if not, you can always
> occasionally move the drive and mount it (via eSATA) on windows and
> compress files to free up space. I have never had a windows’ compressed
> file fail to be read (under Linux) after it was compressed by windows on
> NTFS. But I guess I should run the experiment rather than just assuming
> I know what’s going on because I share drives between linux and windows
> freely (with compression enabled on NTFS and files compressed).
> Happy Holidays!!

It is possible that compressed files read in Linux, but can not be
compressed (in Linux). If compression is possible, it would be interesting.


Cheers / Saludos,

Carlos E. R.
(from 11.4, with Evergreen, x86_64 “Celadon” (Minas Tirith))

On 2012-12-27 02:26, ratzi wrote:
> One of the systems I have is an old Pentium III PC,
> on which openSUSE 12.1 installs fine from the DVD,
> but which on the other hand won’t boot from the 12.1 live CD !

The live CD needs more memory.


Cheers / Saludos,

Carlos E. R.
(from 11.4, with Evergreen, x86_64 “Celadon” (Minas Tirith))

> I really like NTFS for data volumes because if its ability to compress
> my huge datafiles (from computational fluid dynamics, etc.). With these
> types of files, compression makes a huge difference on the number if
> physical hard drives I have to maintain - big text files are massively
> compressible - can make a 2TB HD effectively a 4TB HD. I think modern
> data+metadata-storage files like NetCDF and HDF5 are also highly
> compressible.

That’s only 50% (2:1) compression; are you sure you’re only getting 4 TB
data on a 2 TB drive? I typically get 10:1 compression with almost any
text file of notable size, and that’s with zip compression (vs. bzip2 or
7z or something where I get even better rates). Anyway, I’m surprised
that’s all you get, but maybe that includes harder-to-compress things like
images or other non-text data.

> Hence my interest in BtrFS - at least for data volumes. Is Butterfs
> really so unstable as to make NTFS preferable? I notice it’s now in
> 12.2 YaST as a seemingly viable option (12.1 x64 SATA3 Phenom x6 4GHz
> 16GB). (BTW: I still keep “/” and “/home” as EXT4, just to be safe.)
> I’m particularly concerned about reports that it doesn’t free-up driveca
> space intelligently…:\

I’ve been using it as my primary volume on my primary box (laptop) for
almost a year and so far it has been fine.

The only concerns I’m aware of regarding disk space being freed up is
around snapshot. The reason for this concern is that btrfs keeps
snapshots which is a really awesome feature that comes from its
copy-on-write (CoW) capabilities. What you should know, though, is that
snapshots aren’t taken every nanosecond or anything, so unless you
manually snapshot the drive (or configure something to automatically do
that for you regularly, or for certain predefined events), btrfs doesn’t
just take snapshots in order to have a good time. If you do not use them
then its CoW capabilities are still available but disk space is freed as
usual when you delete files.

Good luck.

On 2012-12-27 14:34, ab wrote:
>> I really like NTFS for data volumes because if its ability to compress
>> my huge datafiles (from computational fluid dynamics, etc.). With these
>> types of files, compression makes a huge difference on the number if
>> physical hard drives I have to maintain - big text files are massively
>> compressible - can make a 2TB HD effectively a 4TB HD. I think modern
>> data+metadata-storage files like NetCDF and HDF5 are also highly
>> compressible.
>
> That’s only 50% (2:1) compression; are you sure you’re only getting 4 TB
> data on a 2 TB drive? I typically get 10:1 compression with almost any
> text file of notable size, and that’s with zip compression (vs. bzip2 or
> 7z or something where I get even better rates). Anyway, I’m surprised
> that’s all you get, but maybe that includes harder-to-compress things like
> images or other non-text data.

He is talking of NTFS internal transparent compression, not compression
by an utility like zip.

And about btrfs, there is another thread here about compression not
working as it should.


Cheers / Saludos,

Carlos E. R.
(from 11.4, with Evergreen, x86_64 “Celadon” (Minas Tirith))

Btrfs (B-tree file system, variously pronounced “Butter F S”, “Butterfuss”, “Better F S”,[4]](http://en.wikipedia.org/wiki/Btrfs#cite_note-CM090622-4) or “B-tree F S”[5]](http://en.wikipedia.org/wiki/Btrfs#cite_note-5)) is a GPL-licensed experimental copy-on-write file system for Linux. Development began at Oracle Corporation in 2007. It is still in heavy development and marked as unstable. Especially when the filesystem becomes full, no-space conditions arise which might make it challenging to delete files.[6]](http://en.wikipedia.org/wiki/Btrfs#cite_note-BTRFS_Stability-6)[7]](http://en.wikipedia.org/wiki/Btrfs#cite_note-7)

Btrfs - Wikipedia, the free encyclopedia