Cannot Access Harddisk

[ridwanshandy]

Hi, I've been using FreeNAS for about a year, and haven't faced any issues. But today I suddenly can't access my Disk, usually I can directly access the Disk as usual through Windows Explorer, but now I can't. But indeed my disk has been full lately, only about 100MB left, then after I checked via the Web GUI, and it turns out my disk is full until 0B remains. Does it cause me to be unable to access my Disk? If so, I need a solution to the problem. Thank You

 

[ridwanshandy]

I also just noticed I'm getting alerts like this, if this is related to my problem

 

[Ericloewe]

The following applies to all systems and is in no way specific to ZFS or TrueNAS:

Do not completely fill your storage! Things will break.

So yeah, start deleting stuff.

 

[NugentS]

And you may not be able to delete stuff. As deleting stuff generally requires some space initially to perform the delete.
You may have lost the pool as a result of running out of space - I hope not

 

[Ericloewe]

ZFS keeps a bit of space reserved to prevent that sort of thing. That said, higher-level protocols are likely to suffer, so deleting stuff over SMB, for instance, may be trickier.

 

[sretalla]

Worst case, you can mount the pool as read-only to get data off it... the data will not be lost, but you may need to re-create the pool to continue using it if you have insufficient space to allow for a delete.

 

[Davvo]

If you have snapshots, you can revert to those.

 

[sretalla]

If you have snapshots, you can revert to those.

Maybe not... in order to revert a snapshot, a change to metadata is required. We're using a Copy on Write filesystem, so those metadata changes must go somewhere in free space before anything else can happen... no free space will mean no-can-do.

 

[Ericloewe]

That's not a likely scenario unless someone's been messing with tunables that shouldn't really be touched. See also https://openzfs.github.io/openzfs-docs/Performance and Tuning/Module Parameters.html#spa-slop-shift

 

[Davvo]

Maybe not... in order to revert a snapshot, a change to metadata is required. We're using a Copy on Write filesystem, so those metadata changes must go somewhere in free space before anything else can happen... no free space will mean no-can-do.

Yikes, he doesn't have a lot of options then. Doesn't ZFS reserve some space for this kind of tasks?

 

[sretalla]

See also https://openzfs.github.io/openzfs-docs/Performance and Tuning/Module Parameters.html#spa-slop-shift

Interesting to see this:

spa_slop_shift​

Normally, the last 3.2% (1/(2^spa_slop_shift)) of pool space is reserved to ensure the pool doesn’t run completely out of space, due to unaccounted changes (e.g. to the MOS). This also limits the worst-case time to allocate space. When less than this amount of free space exists, most ZPL operations (e.g. write, create) return error:no space (ENOSPC).

Does that mean we will see the used space stop at 97% (seems to be at 100% here)? or will the slop space exist outside of the available/free space?

Doesn't ZFS reserve some space for this kind of tasks?

Indeed it does, see above. I guess there may or may not be a lot of ways for that space to also be consumed (or deliberately reduced).

 

[Davvo]

Does that mean we will see the used space stop at 97% (seems to be at 100% here)? or will the slop space exist outside of the available/free space?

I was under the impression it existed outside of the usable space (and as such of the % we see in those panels).

 

[sretalla]

I was under the impression it existed outside of the usable space (and as such of the % we see in those panels).

Me too, but this wording from the OpenZFS doc gives me some concern that it isn't.

When less than this amount of free space exists, most ZPL operations (e.g. write, create) return error:no space (ENOSPC).

 

[ridwanshandy]

Sorry for my many questions, I'm pretty new to this. But is there any way to delete some files/folders from Disk via the Shell on Web GUI?

 

[Ericloewe]

Yes, of course. Your pools are mounted at /mnt/poolname

 

[Davvo]

Then:

rm

man.freebsd.org

rmdir

man.freebsd.org

 

[WI_Hedgehog]

As a note: Since the pool was filled over 75%, over 80%, over 85%, and over 90%, that pool needs to be backed up completely, deleted, re-created, and re-loaded. The fragmentation (as it went over 80%) is going to dog it for a good long time otherwise, regardless of how much you delete.

You might need some of these to make it happen, live an learn.

 

[Davvo]

Imho if he deletes to reach something like 75% he could try first a balancing (defragmenting) script. It will take a while, but he might save some money to put in bigger disks.

 

[WI_Hedgehog]

True, though if he doesn't have good 3-2-1 backups he should find some sort of solution.

Now, maybe this isn't the case, but I've found people who run their main storage platform (whatever that is) out of space tend to not have any backups. If that's the case then starting with something fast, simple, understandable, and immediate is really important.

 

[ridwanshandy]

Yes, of course. Your pools are mounted at /mnt/poolname

Then:

rm

man.freebsd.org

rmdir

man.freebsd.org

Wow, it worked! I tried using the rm command and was able to delete some data on my disk. Now I can access my disk normally through Windows Explorer. Thanks to everyone who helped me solve this problem.