STORJ usable space, ext4-reservation - STORJ optimization

Hello together,

I got one drive which has 20 TB.

When I set the reserved space to 0 only 18,1 TB are appearig as Size in duf:

Now the recommondation from the STORJ team is to leave 10%. So to basicly use the same 18,1 TB as in Size.

But where does the 10% come from? By the filesystem ext4 it is said that data is lost after 5% of the drive, not 10%. So basicly 5% further could be used without problems and data loss?

Thanks and kind regards,

10% is a safest margin. And it’s “only” a recommendation. Based on your experience and observation of the node, you should determine whether you want to push it a little further. I would start with 10% and extend reduce later if it looks safe.

Also, 18.1 is in Tebibytes:
image

2 Likes

At first it is for the database files, if you’ve got them stored on the same drive as the STORJ-files.
Second it’s because of the nature of the filesystem to become a bit defragmented in the end. So you might end up with not-enough-space errors, because of too few continuous extents or experience lower throughput. Although, STORJ doesn’t need that much troughtput in the end (at most experienced 30MiB/minute here).
But with a drive of 18TiB it’s probably not of any use to reserve 1.8TiB. Probably even 500GB will do.
Moreover, chances are you don’t fill the space in the foreseeable future.

BTW: Is the drive completely filled up with STORJ-data already? Otherwise you could consider partitioning the drive in such a way, that you “reserve” the space for STORJ in order not to conflict with your system.

1 Like

How would you reserve space for STORJ? Currently its formatted in ext4 with -m 0. The type is also 64-bit.

First, I would consider how much space STORJ may eat of my drive.
Then second, I would partition my drive in such a way that it has that space for itself (so shrink the filesystem, than shrink the filesystem with fdisk, gdisk or parted also depending on the drive layout (MBR or GPT)).
If I was unsure how much that space might be in the future, I would create an LVM
Be aware of the fact, that it’s possible to extend the size of your STORJ-node on the fly.
I would keep a little spare (reserve blocks) for the file system as in 1% or something.

But the first questions are:

  1. Are you already running a node?
  2. How much space do you want to sacrifice for STORJ?

The drive is partitioned with GPT.

LVM should not be possible anymore. I would need to enterily format the drive and lose the node.

Yes there is a node running already. Currently with a size of 18,1 TB and I plan to increase it. It’s not urgent because its only filled to 70% and not 90%.

I would entirely run all the space for STORJ on this drive. Then set it so 19,8 TB? 99%?

Well, probably 200GB will be enough. But the third reason I forgot is when STORJ has a bug. I actually don’t see the urgency to make it as little as possible. 100GB is making you at most $0.25/month. Losing your 20TB node is a kind of small disaster. So keep it at least something like 500GB, that’s what I would do in each case.

1 Like

Nothing is lost. You may just get lower performance when the volume fills up over 95%. ext4 is much better at managing fragmentation than ext3, you should be fine.

See this post:

https://listman.redhat.com/archives/ext3-users/2009-January/msg00026.html

So for storj, I’d say you can fill it to the brim. Put databases on another partition, if you care about them, or perhaps, on a separate SSD, to give them some breathing room, and to avoid dragging down node performance for meaningless sync writes just to have pretty plots in the ui.