error *** Disk space is too low!

[DireWolfM14]

This is maybe more help with Ubuntu than bitcoin core.  I know I have plenty of room on the hard drive, but I'm getting an error in the debug log file claiming the disk space is too low.

This from fdisk:

Code:

         Device: /dev/sda3
          Start: 3147776
            End: 2930274303
        Sectors: 2927126528
           Size: 1.4T
           Type: Linux LVM
      Type-UUID: E6D6D379-F507-44C2-A23C-238F2A3DF928
           UUID: 14389213-92EC-4E00-AAB3-34706F9E0FF6

I originally had the partition set to Linux filetype and it showed the same disk size, but I had been the same error.    I thought maybe converting it would help.

From debug.log

Code:

2021-08-30T02:29:00Z *** Disk space is too low!
2021-08-30T02:29:00Z Error: Disk space is too low!
2021-08-30T02:29:00Z RewindBlockIndex: unable to flush state to disk (Disk space is too low!)
2021-08-30T02:29:00Z Shutdown requested. Exiting.
2021-08-30T02:29:00Z Shutdown: In progress...
2021-08-30T02:29:00Z scheduler thread exit
2021-08-30T02:29:00Z *** Disk space is too low!
2021-08-30T02:29:00Z Error: Disk space is too low!
2021-08-30T02:29:00Z ForceFlushStateToDisk: failed to flush state (Disk space is too low!)
2021-08-30T02:29:00Z *** Disk space is too low!
2021-08-30T02:29:00Z Error: Disk space is too low!
2021-08-30T02:29:00Z ForceFlushStateToDisk: failed to flush state (Disk space is too low!)
2021-08-30T02:29:00Z Shutdown: done

Any ideas what could be causing this?

Machine: Dell Optiplex with i5 processor and 16Gb of ram.
OS: Ubuntu server 20.04.3
Core: 0.21.1

[1715650105]

1715650105

[1715650105]

1715650105

[ranochigo]

df -h would return the output with the free space, could you try that? Are you pointing Core to the correct directory? Can you navigate to your data directory and run ls -l? It should show the permissions for the file and whether you can write to it.

[DireWolfM14]

df -h would return the output with the free space, could you try that? Are you pointing Core to the correct directory? Can you navigate to your data directory and run ls -l? It should show the permissions for the file and whether you can write to it.

Thanks for the help, I think that found it:

Code:

/dev/mapper/ubuntu--vg-ubuntu--lv        196G  186G  5.3M 100% /

It's a 1.5TB hard drive.  Now that I see this I think I've ran into this before, where Ubuntu wants to believe the hard drive is only 200 Gigs.  For the life of me I can't remember how to fix it.

[ranochigo]

Code:

/dev/mapper/ubuntu--vg-ubuntu--lv        196G  186G  5.3M 100% /

It's a 1.5TB hard drive.  Now that I see this I think I've ran into this before, where Ubuntu wants to believe the hard drive is only 200 Gigs.  For the life of me I can't remember how to fix it.

I suspect that it might be due to the partitions being allocated wrongly. You might've to resize the volumes to the correct sizes.

[HCP]

What do you see when you look at parted/gparted? Does it show the partition as taking up the full drive size or is there a bunch of "unallocated" disk space?

When you originally created the partition... did you clone it from another drive or manually create it?

[LoyceV]

My first question would be: Why use LVM? (I've never used it).
I always use this partition type:

Code:

83  Linux

And not this one:

Code:

8e  Linux LVM

(Codes taken from fdisk help)

[DireWolfM14]

What do you see when you look at parted/gparted? Does it show the partition as taking up the full drive size or is there a bunch of "unallocated" disk space?

Yes, parted showed that the partition was only 198GB.  I thought I had used parted to fix that issue in the past, but I couldn't remember how I did it, nor could I find the instructions last night.

When you originally created the partition... did you clone it from another drive or manually create it?

No, it wasn't a clone.  I performed a fresh install on a used HD, but I didn't do anything with partitions.  I just selected the check box to "Use an entire disk," and left everything else on defaults.

My first question would be: Why use LVM? (I've never used it).[/url])

I didn't have a LVM partition initially, it was Linux filetype at first.  I was having the same problem with disk space with the original file type also.  I converted the partition type to LVM because I suspected it was an issue with the partition, and thought that would help me.  IIRC the last time this happened to me I already had a LVM partition (probably because I wanted that one encrypted,) and was able to adjust the partition size without screwing things up.  I was up later than I should have been goofing around with it last night and finally gave up.

First of all, you need to find out how LVM configure your hard drive partition. You could use tools such as system-config-lvm (also called LVM GUI) to find out.

Thanks for the suggestion, but I think it might be too late for that now.  I didn't have too much time invested in the system, so I decided to start over.  This morning I booted up from the sever installation usb, and played around with the partition settings.  I don't know if it's something to do with Dell systems, but this is the second time this type of thing has happened to me.  Once it was with a brand new SSD, also on a Dell system.  For some reason the server install wants to set the partition size to 200GB.  It seems like selecting the check box to use the entire disk doesn't actually partition the entire disk (barring what's needed for the boot sector, of course.)  I found the setting in the partition options while goofing around with it this morning, so I think I'll get it figured out.

Thanks for all the help.

ETA: I am using UEFI, but I don't know if that has any thing to do with it.

[LoyceV]

I've seen fake USB-sticks with a smaller size than advertised. I've never seen it with SSD, but still: any chance you bought the SSD at a very shady supplier?

Other than that, I would manually fdisk the disk: wipe it, create a normal Linux partition, format as ext4, then check the size.

[DireWolfM14]

I've seen fake USB-sticks with a smaller size than advertised. I've never seen it with SSD, but still: any chance you bought the SSD at a very shady supplier?

No, it's a real deal WD Red 1TB SSD, purchased from the WD Amazon store.  That system has been running with a full node and ElectrumX for well over a year now.

Other than that, I would manually fdisk the disk: wipe it, create a normal Linux partition, format as ext4, then check the size.

That's the goal.  I should be able to set it properly during the server install, but if that still gives me trouble I'll start up the system with a live-boot (Desktop) usb and obliterate all the partitions.

[HCP]

Seems at least one other person has run into this exact issue with Ubuntu Server and LVM: https://askubuntu.com/questions/1269493/ubuntu-server-20-04-1-lts-not-all-disk-space-was-allocated-during-installation

The default setup seems to only create a 200GB partition and you need to faff about extending it manually. Thankfully, they also list a solution

Like myself, a user in that askubuntu thread seems to think that it might be a default strategy of only using a small portion as the "root" partition, so you can setup the rest as data only partitions etc.

[DireWolfM14]

Seems at least one other person has run into this exact issue with Ubuntu Server and LVM: https://askubuntu.com/questions/1269493/ubuntu-server-20-04-1-lts-not-all-disk-space-was-allocated-during-installation

The default setup seems to only create a 200GB partition and you need to faff about extending it manually. Thankfully, they also list a solution

Nice, I'll make sure to look this up if I run into this again.

I was able to configure the the whole hard drive as ext4 partition during the reinstall.  I just goofed around with the partition settings until I figured it out; I had to delete the partitions, and create a new one to mount at /.  A dialogue pops up and lists the available unpartitioned space and asks how much of it you want to use; you have enter the desired disk space manually.

Code:

Filesystem                               Size  Used Avail Use% Mounted on
udev                                     7.8G     0  7.8G   0% /dev
tmpfs                                    1.6G  1.4M  1.6G   1% /run
/dev/sda2                                1.4T  492G  813G  38% /
tmpfs                                    7.8G     0  7.8G   0% /dev/shm
tmpfs                                    5.0M     0  5.0M   0% /run/lock
tmpfs                                    7.8G     0  7.8G   0% /sys/fs/cgroup
/dev/loop1                                33M   33M     0 100% /snap/snapd/12704
/dev/loop0                                33M   33M     0 100% /snap/snapd/12883
/dev/loop3                                71M   71M     0 100% /snap/lxd/21029
/dev/loop2                                56M   56M     0 100% /snap/core18/2128
/dev/sda1                                511M  5.3M  506M   2% /boot/efi

Code:

  "chain": "main",
  "blocks": 699026,
  "headers": 699026,
  "bestblockhash": "0000000000000000000f5bb624fd7f53cf1684a1dfdbda315f0d61bcf6c438de",
  "difficulty": 17615033039278.88,
  "mediantime": 1630777399,
  "verificationprogress": 0.9999930653217675,
  "initialblockdownload": false,
  "chainwork": "0000000000000000000000000000000000000000212f9da344cfa078b12a79d6",
  "size_on_disk": 411886875166,

Like myself, a user in that askubuntu thread seems to think that it might be a default strategy of only using a small portion as the "root" partition, so you can setup the rest as data only partitions etc.

I suspect you're right, that was my initial thinking as well.  I can see that bein helpful in some situations.   

[NotATether]

You can actually enlarge LVM "container" partitions if the unallocated space is on another partition by running vgextend <volume group name you need to look up> /dev/xvd<X> (replace <X> with the partition containing the free space).

Then you can just extend the 200GB logical volume in the volume group by running something like lvextend -l +100%FREE /dev/<logical volume path> and then expand the ext4 filesystem inside using resize2fs /dev/<logical volume path>.

[10_sjdovn_10]

Do it related to bigger block sizes (if you already increased it) with unsuited filesystem ?
It may when your program write files to hard disk it occupy 2x or more space on disk and it runs out of space.   

[LoyceV]

Besides, you can't just increase block size limit without getting approval from Bitcoin community.

In this case: block size is related to the filesystem, not Bitcoin