You are not logged in.
I have the following problem:
according to df my home directory has free space and is fully occupied the same time:
/dev/sda6 40G 29G 0 100% /homeThis is permanent and does not disappear after a reeboot.
Withe the help of ddg-ai I made a few checks and also tried a repair but was not successful.
Here the results of the checks:
btrfs filesystem show
Label: 'devuanroot' uuid: 2b6fb193-4c1a-4c76-a9a6-8dd1fc5b85b2
Total devices 1 FS bytes used 44.83GiB
devid 1 size 58.59GiB used 57.59GiB path /dev/sda3
Label: 'devuanhome' uuid: 5207a0ce-102b-475a-ba38-64d62eecd38b
Total devices 1 FS bytes used 28.37GiB
devid 1 size 39.06GiB used 39.06GiB path /dev/sda6
Label: 'sammelordner' uuid: ac2097f4-8bb0-4fa3-b282-fac690400a1d
Total devices 1 FS bytes used 205.13GiB
devid 1 size 255.31GiB used 206.02GiB path /dev/sda7
Label: 'antixroot' uuid: f98c69d7-4500-4706-8381-b1d22c94364d
Total devices 1 FS bytes used 384.00KiB
devid 1 size 58.59GiB used 1.02GiB path /dev/sda2
Label: 'antixhome' uuid: 07ecdfdf-12b8-4f6b-9607-79d5d9723d62
Total devices 1 FS bytes used 112.00KiB
devid 1 size 9.77GiB used 20.00MiB path /dev/sda5
Label: 'antixhome' uuid: 726cbd5c-87dd-4126-90e0-70e7fafae460
Total devices 1 FS bytes used 112.00KiB
devid 1 size 39.06GiB used 20.00MiB path /dev/sda8findmnt -t btrfs
TARGET SOURCE FSTYPE OPTIONS
/ /dev/sda3 btrfs rw,noatime,ssd,space_cache,subvolid=5,subvol=/
└─/home /dev/sda6 btrfs rw,noatime,ssd,space_cache,subvolid=5,subvol=/
└─/home/matthias/Sammelordner /dev/sda7 btrfs rw,noatime,ssd,space_cache,subvolid=5,subvol=/btrfs scrum after repair:
root@blechdepp:/home# btrfs scrub start -B -R /home
scrub done for 5207a0ce-102b-475a-ba38-64d62eecd38b
Scrub started: Thu Apr 9 11:01:06 2026
Status: finished
Duration: 0:00:54
data_extents_scrubbed: 586281
tree_extents_scrubbed: 32016
data_bytes_scrubbed: 29936181248
tree_bytes_scrubbed: 524550144
read_errors: 0
csum_errors: 0
verify_errors: 1
no_csum: 32170
csum_discards: 7276468
super_errors: 0
malloc_errors: 0
uncorrectable_errors: 1
unverified_errors: 0
corrected_errors: 0
last_physical: 41892708352
ERROR: there are uncorrectable errorsbtrfs scrum before repair:
root@blechdepp:~# btrfs scrub start -B -R /home
scrub done for 5207a0ce-102b-475a-ba38-64d62eecd38b
Scrub started: Thu Apr 9 10:30:39 2026
Status: finished
Duration: 0:00:56
data_extents_scrubbed: 587056
tree_extents_scrubbed: 32050
data_bytes_scrubbed: 29985071104
tree_bytes_scrubbed: 525107200
read_errors: 0
csum_errors: 0
verify_errors: 0
no_csum: 32170
csum_discards: 7288404
super_errors: 0
malloc_errors: 0
uncorrectable_errors: 0
unverified_errors: 0
corrected_errors: 0
last_physical: 41892708352repair:
root@blechdepp:~# btrfs check --force --repair /dev/sda6
enabling repair mode
Opening filesystem to check...
WARNING: filesystem mounted, continuing because of --force
Checking filesystem on /dev/sda6
UUID: 5207a0ce-102b-475a-ba38-64d62eecd38b
[1/7] checking root items
Fixed 0 roots.
[2/7] checking extents
No device size related problem found
[3/7] checking free space cache
cache and super generation don't match, space cache will be invalidated
[4/7] checking fs roots
reset nbytes for ino 19094119 root 5
[5/7] checking only csums items (without verifying data)
[6/7] checking root refs
[7/7] checking quota groups skipped (not enabled on this FS)
found 30510194688 bytes used, no error found
total csum bytes: 29153616
total tree bytes: 525123584
total fs tree bytes: 454262784
total extent tree bytes: 30703616
btree space waste bytes: 87900281
file data blocks allocated: 206212526080
referenced 70746300416I had to use --force since I cannot umount /home
A hardware check:
root@blechdepp:~# smartctl -a /dev/sda6
smartctl 7.3 2022-02-28 r5338 [x86_64-linux-6.1.0-44-amd64] (local build)
Copyright (C) 2002-22, Bruce Allen, Christian Franke, www.smartmontools.org
=== START OF INFORMATION SECTION ===
Model Family: Samsung based SSDs
Device Model: Samsung SSD 860 EVO 500GB
Serial Number: S3Z2NB1K309289F
LU WWN Device Id: 5 002538 e402803d9
Firmware Version: RVT01B6Q
User Capacity: 500.107.862.016 bytes [500 GB]
Sector Size: 512 bytes logical/physical
Rotation Rate: Solid State Device
Form Factor: 2.5 inches
TRIM Command: Available, deterministic, zeroed
Device is: In smartctl database 7.3/5319
ATA Version is: ACS-4 T13/BSR INCITS 529 revision 5
SATA Version is: SATA 3.1, 6.0 Gb/s (current: 6.0 Gb/s)
Local Time is: Thu Apr 9 10:34:27 2026 CEST
SMART support is: Available - device has SMART capability.
SMART support is: Enabled
=== START OF READ SMART DATA SECTION ===
SMART overall-health self-assessment test result: PASSED
General SMART Values:
Offline data collection status: (0x00) Offline data collection activity
was never started.
Auto Offline Data Collection: Disabled.
Self-test execution status: ( 0) The previous self-test routine completed
without error or no self-test has ever
been run.
Total time to complete Offline
data collection: ( 0) seconds.
Offline data collection
capabilities: (0x53) SMART execute Offline immediate.
Auto Offline data collection on/off support.
Suspend Offline collection upon new
command.
No Offline surface scan supported.
Self-test supported.
No Conveyance Self-test supported.
Selective Self-test supported.
SMART capabilities: (0x0003) Saves SMART data before entering
power-saving mode.
Supports SMART auto save timer.
Error logging capability: (0x01) Error logging supported.
General Purpose Logging supported.
Short self-test routine
recommended polling time: ( 2) minutes.
Extended self-test routine
recommended polling time: ( 85) minutes.
SCT capabilities: (0x003d) SCT Status supported.
SCT Error Recovery Control supported.
SCT Feature Control supported.
SCT Data Table supported.
SMART Attributes Data Structure revision number: 1
Vendor Specific SMART Attributes with Thresholds:
ID# ATTRIBUTE_NAME FLAG VALUE WORST THRESH TYPE UPDATED WHEN_FAILED RAW_VALUE
5 Reallocated_Sector_Ct 0x0033 100 100 010 Pre-fail Always - 0
9 Power_On_Hours 0x0032 094 094 000 Old_age Always - 26176
12 Power_Cycle_Count 0x0032 097 097 000 Old_age Always - 2985
177 Wear_Leveling_Count 0x0013 094 094 000 Pre-fail Always - 87
179 Used_Rsvd_Blk_Cnt_Tot 0x0013 100 100 010 Pre-fail Always - 0
181 Program_Fail_Cnt_Total 0x0032 100 100 010 Old_age Always - 0
182 Erase_Fail_Count_Total 0x0032 100 100 010 Old_age Always - 0
183 Runtime_Bad_Block 0x0013 100 100 010 Pre-fail Always - 0
187 Uncorrectable_Error_Cnt 0x0032 100 100 000 Old_age Always - 0
190 Airflow_Temperature_Cel 0x0032 060 044 000 Old_age Always - 40
195 ECC_Error_Rate 0x001a 200 200 000 Old_age Always - 0
199 CRC_Error_Count 0x003e 100 100 000 Old_age Always - 0
235 POR_Recovery_Count 0x0012 099 099 000 Old_age Always - 128
241 Total_LBAs_Written 0x0032 099 099 000 Old_age Always - 107438634846
SMART Error Log Version: 1
No Errors Logged
SMART Self-test log structure revision number 1
No self-tests have been logged. [To run self-tests, use: smartctl -t]
SMART Selective self-test log data structure revision number 1
SPAN MIN_LBA MAX_LBA CURRENT_TEST_STATUS
1 0 0 Not_testing
2 0 0 Not_testing
3 0 0 Not_testing
4 0 0 Not_testing
5 0 0 Not_testing
Selective self-test flags (0x0):
After scanning selected spans, do NOT read-scan remainder of disk.
If Selective self-test is pending on power-up, resume after 0 minute delay.Offline
Hello:
I have the following problem:
according to df my home directory has free space and is fully occupied the same time:
/dev/sda6 40G 29G 0 100% /home
I'd have a look here https://btrfs.readthedocs.io/en/stable/ … index.html and here https://wiki.debian.org/Btrfs
Best,
A.
Offline
Hello Altoid,
Thank you for your hint.
With the expression "ENOSPC" (Error: No space left on device) on the the 2nd link, I found a german page that seems to fit to my problem:
https://www.slicewise.net/debian/balanc … eisystems/
According to that it couldbe that btrfs "thinks" the partition is full, bit it isn't.
Caused by btrfs not realesing space that is not needed any more. (it is actually more complicated than that)
To solve the problem the size of the blocked partition could be temporary increased, that there is enough space for btrfs and then balance the fs again:
cd /mnt
mkdir fulldisk
#the "full" btrfs-partition is /dev/sda2
mount /dev/sda2 fulldisk
#add a USB-stick to the 'full' btrfs partition
btrfs device add /dev/sdb fulldisk
#balancing
btrfs balance start fulldisk
#remove USB-Stick from btrfs-partition
btrfs device delete /dev/sdb fulldiskWell I tried this with the stick that was plugged in wit an antic Live systemand forced the add as I need not the data on the stick any more.
But something went wrong. Wether I could run the balancing nor could I remove the stick from the btrfs-partition.
I did a reboot and now the "full" btrfs-partition could not be mounted any more. Also when I try to start a btrfs repair action it aborts with the error message:
root@blechdepp:~# btrfs check --repair /dev/sda6Error:
Chunk[256, 228, 37606129664]: length(1073741824), offset(37606129664), type(1) is not found in block group
well this shouldn't happen, extent record overlaps but is metadata? [37339414528, 16384]
abortedIt seems it is time ti format /dev/sda6.
Or is there another option?
Would it be wiser to change to ext4 fs instead of btrfs?
Offline
Hello:
Thank you ...
You're welcome.
It was more a recommendation than anything else.
... a german page that seems to fit to my problem ...
... something went wrong.
... time ti format /dev/sda6.
I cannot opine on all that.
All I can say is that every time I have come across the string btrfs it is usually associated with a problem.
Not all solvable, many fatal.
As an example, see this thread from a couple of years ago: https://dev1galaxy.org/viewtopic.php?id=5631
... is there another option?
... wiser to change to ext4 fs instead of btrfs?
I'll answer your questions by expressing my point of view* with respect to using filesystems other than the one Devuan uses by default.
* which does not imply or pretend any wisdom on my behalf. 8^°
To wit:
Choosing anything other than the default Devuan ext4 filesystem implies that you are absolutely sure that you have a use case that really justifies your doing so, a second implication being that you are sufficiently versed in the options being considered.
This (quite obviously) also applies to choosing any init package other than the default Devuan sysvinit, something of a trend in the last few years.
From where I see it, keeping the default options is a basic part of the KISS principle.
ie: if it works as advertised / needed, is adequately supported and has not given you any grief, use the default.
In my case as a 100% Linux user for the last 14 years (the last 8 or so with Devuan), I have never (ever) had any isssues with sysvinit or ext4.
As always, just my $0.02.
YMMV.
That said and assuming that you have all your data and configurations properly backed up, I'd say that you may want to consider getting rid of btrfs and proceed to format whatever disk arrangement you have to ext4.
ie: all the drives, no mixing filesystems.
Best,
A.
Offline
BTRFS interests me a lot, but I have hesitated to use it for years now. If I decide to give it a try, I will probably put /home on a separate partition (or disk) and format it as ext4. That way, if BTRFS causes me any serious problems, my data won't be directly involved.
Last edited by pcalvert (Today 18:35:57)
Offline