Is it safe to resize a rock storage file?

Previous Topic Next Topic
 
classic Classic list List threaded Threaded
7 messages Options
Reply | Threaded
Open this post in threaded view
|

Is it safe to resize a rock storage file?

duanyao
Hi,

Is it safe to resize a rock storage file as follow (while squid is not
running)?

1) Increase a rock storage file by increasing the size specified in the
configuration file;

2) Decrease a rock storage file by decreasing the size specified in the
configuration file and run `truncate --size <new size> rock_file`;

By "safe" I mean no rubbish data will ever be delivered to clients after
resizing, while loss of some cached data is OK.


Regards,

Duan, Yao



_______________________________________________
squid-users mailing list
[hidden email]
http://lists.squid-cache.org/listinfo/squid-users
Reply | Threaded
Open this post in threaded view
|

Re: Is it safe to resize a rock storage file?

Alex Rousskov
On 10/16/2017 06:26 AM, duanyao wrote:

> Is it safe to resize a rock storage file as follow (while squid is not
> running)?
>
> 1) Increase a rock storage file by increasing the size specified in the
> configuration file;

I would recommend running truncate after this as well because that is
what Squid does when it initializes the database (squid -z).


> 2) Decrease a rock storage file by decreasing the size specified in the
> configuration file and run `truncate --size <new size> rock_file`;
>
> By "safe" I mean no rubbish data will ever be delivered to clients after
> resizing, while loss of some cached data is OK.

I have not tested this, but I believe the above operations are safe to
perform while Squid is not running. The second operation may generate
many warnings during Squid startup as Squid discovers and complains
about corrupted entries.

Alex.
_______________________________________________
squid-users mailing list
[hidden email]
http://lists.squid-cache.org/listinfo/squid-users
Reply | Threaded
Open this post in threaded view
|

Re: Is it safe to resize a rock storage file?

Amos Jeffries
Administrator
In reply to this post by duanyao
On 17/10/17 01:26, duanyao wrote:

> Hi,
>
> Is it safe to resize a rock storage file as follow (while squid is not
> running)?
>
> 1) Increase a rock storage file by increasing the size specified in the
> configuration file;
>
> 2) Decrease a rock storage file by decreasing the size specified in the
> configuration file and run `truncate --size <new size> rock_file`;
>
> By "safe" I mean no rubbish data will ever be delivered to clients after
> resizing, while loss of some cached data is OK.

Hell No.

*none* of Squids caches should be manipulated manually. Especially while
the proxy is running. The UFS based caches are a lot more forgiving of
file deletion, but that is an artifact of their lazy validation.

rock cache is a single file with more similarities to SQL-type databases
or a memmap swap file than Squids other cache areas. The -z process for
rock caches actively formats the file used for data storage into cells
and blocks. Changing its size manually will definitely lead to some form
of corruption.

Adding a tool for properly managing these type of changes to caches has
been on my wishlist for many years now and the design is mostly planned
out. Please discuss on squid-dev if you are interested in picking up
that project.

Amos
_______________________________________________
squid-users mailing list
[hidden email]
http://lists.squid-cache.org/listinfo/squid-users
Reply | Threaded
Open this post in threaded view
|

Re: Is it safe to resize a rock storage file?

Alex Rousskov
On 10/16/2017 09:23 AM, Amos Jeffries wrote:

> The -z process for
> rock caches actively formats the file used for data storage into cells
> and blocks.

Not really. "squid -z" adds a small db header, but the rest of the
database is assumed to be nothing but zeros. Squid -z used to fill the
whole db file with zeros (see SLOWLY_FILL_WITH_ZEROS), but I believe we
stopped doing that (by default) and expect an "enlarging truncate" to
have the same side effect. The comit log may have more info about that.


> Changing its size manually will definitely lead to some form
> of corruption.

What makes you think that? Bugs notwithstanding, there are three cases
to consider AFAICT:

* Adding a partial empty slot should be a no-op because Squid will not
notice the added space after rounding the number of slots down.

* Adding a full all-zeros slot will not affect any data already stored
in the database -- nothing will point to that new slot. It will be used
for new cache entries.

* Removing a slot, whole or partial, will invalidate the cache entry
that was using that slot (if any). The affected entry will not be added
to the shared memory index. Skipping an entry should not lead to cache
corruption. It will lead to loss of cache data (and probably some
warnings) but that was explicitly allowed in the original question.

Please let me know if I missed something or if there are reasons to
believe there are bugs affecting the above logic.


Thank you,

Alex.
_______________________________________________
squid-users mailing list
[hidden email]
http://lists.squid-cache.org/listinfo/squid-users
Reply | Threaded
Open this post in threaded view
|

Re: Is it safe to resize a rock storage file?

Amos Jeffries
Administrator
On 17/10/17 07:05, Alex Rousskov wrote:

> On 10/16/2017 09:23 AM, Amos Jeffries wrote:
>
>> The -z process for
>> rock caches actively formats the file used for data storage into cells
>> and blocks.
>
> Not really. "squid -z" adds a small db header, but the rest of the
> database is assumed to be nothing but zeros. Squid -z used to fill the
> whole db file with zeros (see SLOWLY_FILL_WITH_ZEROS), but I believe we
> stopped doing that (by default) and expect an "enlarging truncate" to
> have the same side effect. The comit log may have more info about that.
>

Oh, I thought each block had a TLV and checksum bits as well.

>
>> Changing its size manually will definitely lead to some form
>> of corruption.
>
> What makes you think that? Bugs notwithstanding, there are three cases
> to consider AFAICT:
>
> * Adding a partial empty slot should be a no-op because Squid will not
> notice the added space after rounding the number of slots down.
>
> * Adding a full all-zeros slot will not affect any data already stored
> in the database -- nothing will point to that new slot. It will be used
> for new cache entries.
>
> * Removing a slot, whole or partial, will invalidate the cache entry
> that was using that slot (if any). The affected entry will not be added
> to the shared memory index. Skipping an entry should not lead to cache
> corruption. It will lead to loss of cache data (and probably some
> warnings) but that was explicitly allowed in the original question.

This last one was what I was referring to as corruption. Though I expect
that *removing* slots would lead memory index pointing to no longer
valid locations in the rock database.

Is it harmless to access out-of-range offsets into a memmap'ed file -
specifically ones which *were* valid when it was initially mapped?

Amos
_______________________________________________
squid-users mailing list
[hidden email]
http://lists.squid-cache.org/listinfo/squid-users
Reply | Threaded
Open this post in threaded view
|

Re: Is it safe to resize a rock storage file?

Alex Rousskov
On 10/16/2017 09:35 PM, Amos Jeffries wrote:
> On 17/10/17 07:05, Alex Rousskov wrote:
>> On 10/16/2017 09:23 AM, Amos Jeffries wrote:
>>> The -z process for
>>> rock caches actively formats the file used for data storage into cells
>>> and blocks.

>> Not really. "squid -z" adds a small db header, but the rest of the
>> database is assumed to be nothing but zeros. Squid -z used to fill the
>> whole db file with zeros (see SLOWLY_FILL_WITH_ZEROS), but I believe we
>> stopped doing that (by default) and expect an "enlarging truncate" to
>> have the same side effect. The comit log may have more info about that.


> Oh, I thought each block had a TLV and checksum bits as well.

There is slot-specific metadata (and associated consistency checks), but
it is designed to work fine with all-zeros (i.e., initial or empty)
slots. Filling a 1TB disk cache with something just to "initialize" it
would be rather wasteful/annoying...

There are no true slot checksums.


>> * Removing a slot, whole or partial, will invalidate the cache entry
>> that was using that slot (if any). The affected entry will not be added
>> to the shared memory index. Skipping an entry should not lead to cache
>> corruption. It will lead to loss of cache data (and probably some
>> warnings) but that was explicitly allowed in the original question.

> This last one was what I was referring to as corruption.

AFAICT, OP has explicitly stated that some loss of cached data is fine
(i.e., it is not considered cache corruption). In the original question,
corruption was defined as "rubbish data delivered to clients".


> Though I expect
> that *removing* slots would lead memory index pointing to no longer
> valid locations in the rock database.

The in-memory index is created from the on-disk metadata. Bugs
notwithstanding, if on-disk metadata contains an incomplete entry (e.g.,
an entry slot pointer pointing beyond the current database boundary),
then Rock will not add that entry to the in-memory index, and, hence,
Squid will not know about that entry existence.


> Is it harmless to access out-of-range offsets into a memmap'ed file -
> specifically ones which *were* valid when it was initially mapped?

Out-of-range accesses are probably deadly, but no such accesses should
be happening due to database size changes. Please note that the question
was about database size changes while Squid "is not running". When Squid
starts, it creates memory segments and builds its in-memory disk index
there from scratch, ignoring any bad on-disk entries.


HTH,

Alex.
_______________________________________________
squid-users mailing list
[hidden email]
http://lists.squid-cache.org/listinfo/squid-users
Reply | Threaded
Open this post in threaded view
|

Re: Is it safe to resize a rock storage file?

duanyao
In reply to this post by Alex Rousskov
在 2017/10/16 下午10:59, Alex Rousskov 写道:

> On 10/16/2017 06:26 AM, duanyao wrote:
>
>> Is it safe to resize a rock storage file as follow (while squid is not
>> running)?
>>
>> 1) Increase a rock storage file by increasing the size specified in the
>> configuration file;
> I would recommend running truncate after this as well because that is
> what Squid does when it initializes the database (squid -z).
>
Ok, I'll do that.
>> 2) Decrease a rock storage file by decreasing the size specified in the
>> configuration file and run `truncate --size <new size> rock_file`;
>>
>> By "safe" I mean no rubbish data will ever be delivered to clients after
>> resizing, while loss of some cached data is OK.
> I have not tested this, but I believe the above operations are safe to
> perform while Squid is not running. The second operation may generate
> many warnings during Squid startup as Squid discovers and complains
> about corrupted entries.
Thanks. I do see those warnings in the log.
>
> Alex.



_______________________________________________
squid-users mailing list
[hidden email]
http://lists.squid-cache.org/listinfo/squid-users