Does the command /deleteblocks delete the mapblocks from the database entirely or it only marks them as invalid?
I deleted everything in range from (7000 -23000 -1000) to (10000 -11500 1000) by 1km thick layers, from bottom to top. Deleting one layer took up to a few minutes, so it must have been deleting something. I also made sure that a few bits from the area were really deleted. I walked into these bits and looked that they generated according to my new mapgen. I certainly didn't explore them again. However, the disc usage was about constant all the time. How is that possible?
Does /deleteblocks actually delete the blocks?
- Hume2
- Member
- Posts: 710
- Joined: Tue Jun 19, 2018 08:24
- GitHub: Hume2
- In-game: Hume2
- Location: Czech Republic
Does /deleteblocks actually delete the blocks?
If you lack the reality, go on a trip or find a job.
-
- Moderator
- Posts: 4096
- Joined: Wed Aug 24, 2011 09:44
- GitHub: sfan5
- IRC: sfan5
- Location: Germany
Re: Does /deleteblocks actually delete the blocks?
Yes, /deleteblocks really deletes the mapblocks. However, SQLite usually does not free up unused space by downsizing its file.
You can force SQLite to free up space using the VACUUM SQL command.
You can force SQLite to free up space using the VACUUM SQL command.
- Hume2
- Member
- Posts: 710
- Joined: Tue Jun 19, 2018 08:24
- GitHub: Hume2
- In-game: Hume2
- Location: Czech Republic
Re: Does /deleteblocks actually delete the blocks?
This makes sense, thanks!
If you lack the reality, go on a trip or find a job.
-
- Member
- Posts: 1118
- Joined: Mon Dec 29, 2014 08:07
- Location: USA
Re: Does /deleteblocks actually delete the blocks?
@sfan5,
Shouldn't the MT engine code that calls out to SQLite then be the appropriate place to use the "VACUUM" statement. This should just be already, a part of the embedded SQL calls.
So as not to place more work on the core devs, and to offer my own SQL expertise, if this is something that should be done, but needs manpower, can you point me to where in the code I can find embedded SQL, or even generated SQL, to help optimize the code?
Shad
Shouldn't the MT engine code that calls out to SQLite then be the appropriate place to use the "VACUUM" statement. This should just be already, a part of the embedded SQL calls.
So as not to place more work on the core devs, and to offer my own SQL expertise, if this is something that should be done, but needs manpower, can you point me to where in the code I can find embedded SQL, or even generated SQL, to help optimize the code?
Shad
- Hume2
- Member
- Posts: 710
- Joined: Tue Jun 19, 2018 08:24
- GitHub: Hume2
- In-game: Hume2
- Location: Czech Republic
Re: Does /deleteblocks actually delete the blocks?
I found this:
VACUUM requires you to have at least twice as bigger disc than your database currently occupies. So if your map occupies more than 50% of HDD, you won't perform it unless you move it somewhere else.
If you install sqlite3, you can open any database and then send SQL commands via terminal.
VACUUM requires you to have at least twice as bigger disc than your database currently occupies. So if your map occupies more than 50% of HDD, you won't perform it unless you move it somewhere else.
If you install sqlite3, you can open any database and then send SQL commands via terminal.
If you lack the reality, go on a trip or find a job.
-
- Member
- Posts: 167
- Joined: Mon May 22, 2017 20:27
Re: Does /deleteblocks actually delete the blocks?
No. Vacuum is a resource-intensive operation that should not be carried out while the server is online/running and/or without explicit request from the user. It's also unnecessary in a large majority of situations (most of the time, map files grow by adding new blocks but old blocks aren't deleted). Even when blocks are deleted, it cannot be assumed that the user/mod author/script also wants to vacuum the database (for example they may just be deleting the blocks so that they can be regenerated fresh, which won't cause the database to grow in size).ShadMOrdre wrote:Shouldn't the MT engine code that calls out to SQLite then be the appropriate place to use the "VACUUM" statement. This should just be already, a part of the embedded SQL calls.
Who is online
Users browsing this forum: No registered users and 13 guests