rock storage and max-swap-rate

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

rock storage and max-swap-rate

Ivan Larionov
Hello.

cache_dir max-swap-rate documentation says that swap in requests contribute to measured swap rate. However in our squid 4 load test we see that read_ops + write_ops significantly exceeds the max-swap-rate we set and squid doesn't limit it.

I tried to set it to 200 to confirm that it actually works and saw that it does. Squid started warning about exceeding max-swap-rate. But looks like real limit is higher than the value we set in configuration.

Hardware:

AWS GP2 EBS (SSD) 600GB, 1500 iops baseline performance, 3000 iops burstable.

Config:

cache_dir rock /mnt/services/squid/cache 435200 swap-timeout=500 max-swap-rate=1200 slot-size=16384

IOPS squid pushes under our load test:

read ~800 ops/sec
write ~1100 ops/sec

In summary it gives us ~1900 ops/sec which exceeds AWS limit of 1500 ops/sec and after spending too much "burst balance" we started getting throttled from AWS side.

Could you please comment on this behavior? What the limit should we set to stay under 1500 ops/sec for swap in + swap out operations?

Thanks.

Squid version:

Squid Cache: Version 4.0.22
Service Name: squid
configure options:  '--program-prefix=' '--prefix=/usr' '--exec-prefix=/usr' '--bindir=/usr/sbin' '--sbindir=/usr/sbin' '--sysconfdir=/etc/squid' '--libdir=/usr/lib' '--libexecdir=/usr/lib/squid' '--includedir=/usr/include' '--datadir=/usr/share' '--sharedstatedir=/usr/com' '--localstatedir=/var' '--mandir=/usr/share/man' '--infodir=/usr/share/info' '--enable-epoll' '--enable-removal-policies=heap,lru' '--enable-storeio=aufs,rock' '--enable-delay-pools' '--with-pthreads' '--enable-cache-digests' '--with-large-files' '--with-maxfd=16384' '--enable-htcp'

--
With best regards, Ivan Larionov.

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

Re: rock storage and max-swap-rate

Alex Rousskov
On 01/18/2018 03:16 PM, Ivan Larionov wrote:

> cache_dir max-swap-rate documentation says that swap in requests
> contribute to measured swap rate. However in our squid 4 load test we
> see that read_ops + write_ops significantly exceeds the max-swap-rate we
> set and squid doesn't limit it.

In this context, a single Squid "op" is a read or write request from
worker to the disker process. These requests are up to one I/O page in
size. A single I/O page is 32*1024 bytes. See Ipc::Mem::PageSize().

* A single read request usually ends up being a single pread(2) system
call that reads at most one I/O page worth of data from disk. See
diskerRead().

* A single write request usually ends up being a single pwrite(2) system
call that writes at most one I/O page worth of data to disk. However, if
that single pwrite() does not write everything a worker has requested to
write, then Squid will make more pwrite() calls, up to 10 calls total.
See diskerWrite().

Within a single cache miss transaction, the rock code should accumulate
small swapout requests from Store into page-size write requests to
disker, but I do not remember how complete those optimizations are: It
is possible that smaller-than-page writes get through to diskers,
increasing the number of write requests. Same for reading cache hits.


What is the "op" in read_ops and write_ops you have measured?


Since Squid does not (and does not want to) have access to low-level
disk stats and since Squid cannot assume exlusive disk ownership, the
rate-limiting feature for rock cache_dirs does not know how many
low-level disk operations the disk is doing and how those operations
correspond to what Squid is asking the disk to do.


HTH,

Alex.


> I tried to set it to 200 to confirm that it actually works and saw that
> it does. Squid started warning about exceeding max-swap-rate. But looks
> like real limit is higher than the value we set in configuration.
>
> Hardware:
>
> AWS GP2 EBS (SSD) 600GB, 1500 iops baseline performance, 3000 iops
> burstable.
>
> Config:
>
> cache_dir rock /mnt/services/squid/cache 435200 swap-timeout=500
> max-swap-rate=1200 slot-size=16384
>
> IOPS squid pushes under our load test:
>
> read ~800 ops/sec
> write ~1100 ops/sec
>
> In summary it gives us ~1900 ops/sec which exceeds AWS limit of 1500
> ops/sec and after spending too much "burst balance" we started getting
> throttled from AWS side.
>
> Could you please comment on this behavior? What the limit should we set
> to stay under 1500 ops/sec for swap in + swap out operations?
>
> Thanks.
>
> Squid version:
>
> Squid Cache: Version 4.0.22
> Service Name: squid
> configure options:  '--program-prefix=' '--prefix=/usr'
> '--exec-prefix=/usr' '--bindir=/usr/sbin' '--sbindir=/usr/sbin'
> '--sysconfdir=/etc/squid' '--libdir=/usr/lib'
> '--libexecdir=/usr/lib/squid' '--includedir=/usr/include'
> '--datadir=/usr/share' '--sharedstatedir=/usr/com'
> '--localstatedir=/var' '--mandir=/usr/share/man'
> '--infodir=/usr/share/info' '--enable-epoll'
> '--enable-removal-policies=heap,lru' '--enable-storeio=aufs,rock'
> '--enable-delay-pools' '--with-pthreads' '--enable-cache-digests'
> '--with-large-files' '--with-maxfd=16384' '--enable-htcp'
>
> --
> With best regards, Ivan Larionov.
>
>
> _______________________________________________
> squid-users mailing list
> [hidden email]
> http://lists.squid-cache.org/listinfo/squid-users
>

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

Re: rock storage and max-swap-rate

Ivan Larionov
Thank you for the fast reply!

read_ops and write_ops is AWS EBS metric and in general it correlates with OS-level reads/s writes/s stats which iostat shows.

So if I understand you correctly max-swap-rate doesn't limit disk IOPS but limits squid swap ops instead and every squid operation could in theory use more than 1 disk IO operation. This means we can't really say "limit swap ops to 1500 because our disk can handle 1500 iops" but should figure out the number after testing different values.

Ok, I suppose I'll just do what Rock documentation says – will test different values and figure out what works for us.

Thanks again.

On Thu, Jan 18, 2018 at 2:54 PM, Alex Rousskov <[hidden email]> wrote:
On 01/18/2018 03:16 PM, Ivan Larionov wrote:

> cache_dir max-swap-rate documentation says that swap in requests
> contribute to measured swap rate. However in our squid 4 load test we
> see that read_ops + write_ops significantly exceeds the max-swap-rate we
> set and squid doesn't limit it.

In this context, a single Squid "op" is a read or write request from
worker to the disker process. These requests are up to one I/O page in
size. A single I/O page is 32*1024 bytes. See Ipc::Mem::PageSize().

* A single read request usually ends up being a single pread(2) system
call that reads at most one I/O page worth of data from disk. See
diskerRead().

* A single write request usually ends up being a single pwrite(2) system
call that writes at most one I/O page worth of data to disk. However, if
that single pwrite() does not write everything a worker has requested to
write, then Squid will make more pwrite() calls, up to 10 calls total.
See diskerWrite().

Within a single cache miss transaction, the rock code should accumulate
small swapout requests from Store into page-size write requests to
disker, but I do not remember how complete those optimizations are: It
is possible that smaller-than-page writes get through to diskers,
increasing the number of write requests. Same for reading cache hits.


What is the "op" in read_ops and write_ops you have measured?


Since Squid does not (and does not want to) have access to low-level
disk stats and since Squid cannot assume exlusive disk ownership, the
rate-limiting feature for rock cache_dirs does not know how many
low-level disk operations the disk is doing and how those operations
correspond to what Squid is asking the disk to do.


HTH,

Alex.


> I tried to set it to 200 to confirm that it actually works and saw that
> it does. Squid started warning about exceeding max-swap-rate. But looks
> like real limit is higher than the value we set in configuration.
>
> Hardware:
>
> AWS GP2 EBS (SSD) 600GB, 1500 iops baseline performance, 3000 iops
> burstable.
>
> Config:
>
> cache_dir rock /mnt/services/squid/cache 435200 swap-timeout=500
> max-swap-rate=1200 slot-size=16384
>
> IOPS squid pushes under our load test:
>
> read ~800 ops/sec
> write ~1100 ops/sec
>
> In summary it gives us ~1900 ops/sec which exceeds AWS limit of 1500
> ops/sec and after spending too much "burst balance" we started getting
> throttled from AWS side.
>
> Could you please comment on this behavior? What the limit should we set
> to stay under 1500 ops/sec for swap in + swap out operations?
>
> Thanks.
>
> Squid version:
>
> Squid Cache: Version 4.0.22
> Service Name: squid
> configure options:  '--program-prefix=' '--prefix=/usr'
> '--exec-prefix=/usr' '--bindir=/usr/sbin' '--sbindir=/usr/sbin'
> '--sysconfdir=/etc/squid' '--libdir=/usr/lib'
> '--libexecdir=/usr/lib/squid' '--includedir=/usr/include'
> '--datadir=/usr/share' '--sharedstatedir=/usr/com'
> '--localstatedir=/var' '--mandir=/usr/share/man'
> '--infodir=/usr/share/info' '--enable-epoll'
> '--enable-removal-policies=heap,lru' '--enable-storeio=aufs,rock'
> '--enable-delay-pools' '--with-pthreads' '--enable-cache-digests'
> '--with-large-files' '--with-maxfd=16384' '--enable-htcp'
>
> --
> With best regards, Ivan Larionov.
>
>
> _______________________________________________
> squid-users mailing list
> [hidden email]
> http://lists.squid-cache.org/listinfo/squid-users
>




--
With best regards, Ivan Larionov.

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

Re: rock storage and max-swap-rate

Amos Jeffries
Administrator
On 19/01/18 12:04, Ivan Larionov wrote:

> Thank you for the fast reply!
>
> read_ops and write_ops is AWS EBS metric and in general it correlates
> with OS-level reads/s writes/s stats which iostat shows.
>
> So if I understand you correctly max-swap-rate doesn't limit disk IOPS
> but limits squid swap ops instead and every squid operation could in
> theory use more than 1 disk IO operation. This means we can't really say
> "limit swap ops to 1500 because our disk can handle 1500 iops" but
> should figure out the number after testing different values.
>
> Ok, I suppose I'll just do what Rock documentation says – will test
> different values and figure out what works for us.
>


If you know what the OS level IOP size is (eg usually 4KB) and the Squid
rock IOP size Alex mentioned of 32KB. That should give you a number to
divide the disk IOPS limit you want with to get a rough estimate for the
appropriate Squid setting.

The tuning bit is just to see how much variance from that is caused by
your traffic objects being different from the 32KB slot size.


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

Re: rock storage and max-swap-rate

Alex Rousskov
In reply to this post by Ivan Larionov
On 01/18/2018 04:04 PM, Ivan Larionov wrote:

> So if I understand you correctly max-swap-rate doesn't limit disk IOPS

Correct. Squid does not know what the disk- or OS-level stats are.


> but limits squid swap ops instead

If you define a "swap op" as reading or writing a single I/O page for
the purpose of swapping in or swapping out a cached object, then yes.
Processing an HTTP transaction may involve reading and writing many I/O
pages. See my original response for a more precise definition.


> and every squid operation could in
> theory use more than 1 disk IO operation.

Yes, depending on the file system, disk, etc.

Ideally, rock cache_dirs should use raw disk partitions, but we do not
have a sponsor for that work.


> This means we can't really say
> "limit swap ops to 1500 because our disk can handle 1500 iops" but
> should figure out the number after testing different values.

Correct.


> Ok, I suppose I'll just do what Rock documentation says – will test
> different values and figure out what works for us.

Sounds like a good plan! You may even find a good/stable correlation
between Squid swap I/O ops and low-level disk I/O ops. Please consider
reporting your findings for others to reuse.


Cheers,

Alex.


> On Thu, Jan 18, 2018 at 2:54 PM, Alex Rousskov wrote:
>
>     On 01/18/2018 03:16 PM, Ivan Larionov wrote:
>
>     > cache_dir max-swap-rate documentation says that swap in requests
>     > contribute to measured swap rate. However in our squid 4 load test we
>     > see that read_ops + write_ops significantly exceeds the max-swap-rate we
>     > set and squid doesn't limit it.
>
>     In this context, a single Squid "op" is a read or write request from
>     worker to the disker process. These requests are up to one I/O page in
>     size. A single I/O page is 32*1024 bytes. See Ipc::Mem::PageSize().
>
>     * A single read request usually ends up being a single pread(2) system
>     call that reads at most one I/O page worth of data from disk. See
>     diskerRead().
>
>     * A single write request usually ends up being a single pwrite(2) system
>     call that writes at most one I/O page worth of data to disk. However, if
>     that single pwrite() does not write everything a worker has requested to
>     write, then Squid will make more pwrite() calls, up to 10 calls total.
>     See diskerWrite().
>
>     Within a single cache miss transaction, the rock code should accumulate
>     small swapout requests from Store into page-size write requests to
>     disker, but I do not remember how complete those optimizations are: It
>     is possible that smaller-than-page writes get through to diskers,
>     increasing the number of write requests. Same for reading cache hits.
>
>
>     What is the "op" in read_ops and write_ops you have measured?
>
>
>     Since Squid does not (and does not want to) have access to low-level
>     disk stats and since Squid cannot assume exlusive disk ownership, the
>     rate-limiting feature for rock cache_dirs does not know how many
>     low-level disk operations the disk is doing and how those operations
>     correspond to what Squid is asking the disk to do.
>
>
>     HTH,
>
>     Alex.
>
>
>     > I tried to set it to 200 to confirm that it actually works and saw
>     that
>     > it does. Squid started warning about exceeding max-swap-rate. But
>     looks
>     > like real limit is higher than the value we set in configuration.
>     >
>     > Hardware:
>     >
>     > AWS GP2 EBS (SSD) 600GB, 1500 iops baseline performance, 3000 iops
>     > burstable.
>     >
>     > Config:
>     >
>     > cache_dir rock /mnt/services/squid/cache 435200 swap-timeout=500
>     > max-swap-rate=1200 slot-size=16384
>     >
>     > IOPS squid pushes under our load test:
>     >
>     > read ~800 ops/sec
>     > write ~1100 ops/sec
>     >
>     > In summary it gives us ~1900 ops/sec which exceeds AWS limit of 1500
>     > ops/sec and after spending too much "burst balance" we started getting
>     > throttled from AWS side.
>     >
>     > Could you please comment on this behavior? What the limit should
>     we set
>     > to stay under 1500 ops/sec for swap in + swap out operations?
>     >
>     > Thanks.
>     >
>     > Squid version:
>     >
>     > Squid Cache: Version 4.0.22
>     > Service Name: squid
>     > configure options:  '--program-prefix=' '--prefix=/usr'
>     > '--exec-prefix=/usr' '--bindir=/usr/sbin' '--sbindir=/usr/sbin'
>     > '--sysconfdir=/etc/squid' '--libdir=/usr/lib'
>     > '--libexecdir=/usr/lib/squid' '--includedir=/usr/include'
>     > '--datadir=/usr/share' '--sharedstatedir=/usr/com'
>     > '--localstatedir=/var' '--mandir=/usr/share/man'
>     > '--infodir=/usr/share/info' '--enable-epoll'
>     > '--enable-removal-policies=heap,lru' '--enable-storeio=aufs,rock'
>     > '--enable-delay-pools' '--with-pthreads' '--enable-cache-digests'
>     > '--with-large-files' '--with-maxfd=16384' '--enable-htcp'
>     >
>     > --
>     > With best regards, Ivan Larionov.
>     >
>     >
>     > _______________________________________________
>     > squid-users mailing list
>     > [hidden email]
>     <mailto:[hidden email]>
>     > http://lists.squid-cache.org/listinfo/squid-users
>     <http://lists.squid-cache.org/listinfo/squid-users>
>     >
>
>
>
>
> --
> With best regards, Ivan Larionov.

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

Re: rock storage and max-swap-rate

Ivan Larionov
In reply to this post by Amos Jeffries
Thanks Amos.

According to AWS docs:

> I/O size is capped at 256 KiB for SSD volumes
> When small I/O operations are physically contiguous, Amazon EBS attempts to merge them into a single I/O up to the maximum size. For example, for SSD volumes, a single 1,024 KiB I/O operation counts as 4 operations (1,024÷256=4), while 8 contiguous I/O operations at 32 KiB each count as 1operation (8×32=256). However, 8 random I/O operations at 32 KiB each count as 8 operations. Each I/O operation under 32 KiB counts as 1 operation.

So it's not so easy to figure out correlation between squid swap ops and AWS EBS ops. What I see from here is:

* Multiple squid swap in or swap out ops reading/writing contiguous blocks could be merged into one 256KB IO operation.
* Random squid operations could be handled as single 32KB IO operation.

On Thu, Jan 18, 2018 at 3:20 PM, Amos Jeffries <[hidden email]> wrote:
On 19/01/18 12:04, Ivan Larionov wrote:
Thank you for the fast reply!

read_ops and write_ops is AWS EBS metric and in general it correlates with OS-level reads/s writes/s stats which iostat shows.

So if I understand you correctly max-swap-rate doesn't limit disk IOPS but limits squid swap ops instead and every squid operation could in theory use more than 1 disk IO operation. This means we can't really say "limit swap ops to 1500 because our disk can handle 1500 iops" but should figure out the number after testing different values.

Ok, I suppose I'll just do what Rock documentation says – will test different values and figure out what works for us.



If you know what the OS level IOP size is (eg usually 4KB) and the Squid rock IOP size Alex mentioned of 32KB. That should give you a number to divide the disk IOPS limit you want with to get a rough estimate for the appropriate Squid setting.

The tuning bit is just to see how much variance from that is caused by your traffic objects being different from the 32KB slot size.


Amos

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



--
With best regards, Ivan Larionov.

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

Re: rock storage and max-swap-rate

Alex Rousskov
On 01/18/2018 05:35 PM, Ivan Larionov wrote:

> * Multiple squid swap in or swap out ops reading/writing contiguous
> blocks could be merged into one 256KB IO operation.

> * Random squid operations could be handled as single 32KB IO operation.

FWIW, on a busy Squid with a large disk cache in a stable state, there
should be virtually no mergeable/contiguous swap requests (first bullet)
due to random nature of rock slot assignment.

Alex.


> On Thu, Jan 18, 2018 at 3:20 PM, Amos Jeffries wrote:
>
>     On 19/01/18 12:04, Ivan Larionov wrote:
>
>         Thank you for the fast reply!
>
>         read_ops and write_ops is AWS EBS metric and in general it
>         correlates with OS-level reads/s writes/s stats which iostat shows.
>
>         So if I understand you correctly max-swap-rate doesn't limit
>         disk IOPS but limits squid swap ops instead and every squid
>         operation could in theory use more than 1 disk IO operation.
>         This means we can't really say "limit swap ops to 1500 because
>         our disk can handle 1500 iops" but should figure out the number
>         after testing different values.
>
>         Ok, I suppose I'll just do what Rock documentation says – will
>         test different values and figure out what works for us.
>
>
>
>     If you know what the OS level IOP size is (eg usually 4KB) and the
>     Squid rock IOP size Alex mentioned of 32KB. That should give you a
>     number to divide the disk IOPS limit you want with to get a rough
>     estimate for the appropriate Squid setting.
>
>     The tuning bit is just to see how much variance from that is caused
>     by your traffic objects being different from the 32KB slot size.
>
>
>     Amos
>
>     _______________________________________________
>     squid-users mailing list
>     [hidden email]
>     <mailto:[hidden email]>
>     http://lists.squid-cache.org/listinfo/squid-users
>     <http://lists.squid-cache.org/listinfo/squid-users>
>
>
>
>
> --
> With best regards, Ivan Larionov.
>
>
> _______________________________________________
> squid-users mailing list
> [hidden email]
> http://lists.squid-cache.org/listinfo/squid-users
>

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

Re: rock storage and max-swap-rate

reinerotto
In reply to this post by Ivan Larionov
>1500 iops baseline performance< Does this include management operations of
the filesystem used ?
And which filesystem is used ? ext4 might be a bad choice, in case not
significantly "degenerated".




--
Sent from: http://squid-web-proxy-cache.1019090.n4.nabble.com/Squid-Users-f1019091.html
_______________________________________________
squid-users mailing list
[hidden email]
http://lists.squid-cache.org/listinfo/squid-users
Reply | Threaded
Open this post in threaded view
|

Re: rock storage and max-swap-rate

Ivan Larionov
Could you please elaborate? What’s wrong with rock on ext4? Which filesystem works better for it?

1500 iops is EBS volume limit and it includes all IO operations and it has no idea about filesystem, it just provides block storage device.

On Jan 21, 2018, at 20:35, reinerotto <[hidden email]> wrote:

>> 1500 iops baseline performance< Does this include management operations of
> the filesystem used ?
> And which filesystem is used ? ext4 might be a bad choice, in case not
> significantly "degenerated".
>
>
>
>
> --
> Sent from: http://squid-web-proxy-cache.1019090.n4.nabble.com/Squid-Users-f1019091.html
> _______________________________________________
> squid-users mailing list
> [hidden email]
> http://lists.squid-cache.org/listinfo/squid-users
_______________________________________________
squid-users mailing list
[hidden email]
http://lists.squid-cache.org/listinfo/squid-users
Reply | Threaded
Open this post in threaded view
|

Re: rock storage and max-swap-rate

Alex Rousskov
On 01/22/2018 02:39 AM, Ivan Larionov wrote:
> What’s wrong with rock on ext4?

ext4 does a lot more than rock needs in most environments. More useless
work usually means more overhead/worse performance. YMMV.


> Which filesystem works better for it?
In most cases, the simpler/dumber the filesystem is, the better. If you
recall, rock's ultimate goal is using a raw disk partition or
equivalent... Rock already does 95+% of what a simple file system does.

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

Re: rock storage and max-swap-rate

reinerotto
In reply to this post by Ivan Larionov
Privet !
>Could you please elaborate? What’s wrong with rock on ext4? <
Default ext4 uses a "journal" of the modifications. Which adds I/O.
Timestamps of filemods are other I/Os. I do not think, that these features
are required for rock. Disabling journal completely will cause loss of data
(cached) in case of disk failure, but this is a very rare event, and will be
recovered over time by filling up cache again. So, in case rock is on its
own private disk/partition, I feel very well to disable journal completely.
For a start:
https://askubuntu.com/questions/573957/disabling-journaling-in-ubuntu-14-04

Dunno whether possible using AWS. As I like to have full control, I do not
use AWS at all.



--
Sent from: http://squid-web-proxy-cache.1019090.n4.nabble.com/Squid-Users-f1019091.html
_______________________________________________
squid-users mailing list
[hidden email]
http://lists.squid-cache.org/listinfo/squid-users
Reply | Threaded
Open this post in threaded view
|

Re: rock storage and max-swap-rate

Matus UHLAR - fantomas
>>Could you please elaborate? What’s wrong with rock on ext4? <

On 22.01.18 17:47, reinerotto wrote:
>Default ext4 uses a "journal" of the modifications. Which adds I/O.
>Timestamps of filemods are other I/Os. I do not think, that these features
>are required for rock. Disabling journal completely will cause loss of data
>(cached) in case of disk failure, but this is a very rare event, and will be
>recovered over time by filling up cache again. So, in case rock is on its
>own private disk/partition, I feel very well to disable journal completely.

I believe that journal is only wirtten to, when you make change at
filesystem level, like creating or removing files.

Since rock storage is one file, journaling only affects it when you create,
enlarge or shrink it, not otherwise.

Thus, ext4 and journalling should not affect the speed of standad work over
rock store.

Please correct me if I'm wrong.

--
Matus UHLAR - fantomas, [hidden email] ; http://www.fantomas.sk/
Warning: I wish NOT to receive e-mail advertising to this address.
Varovanie: na tuto adresu chcem NEDOSTAVAT akukolvek reklamnu postu.
WinError #99999: Out of error messages.
_______________________________________________
squid-users mailing list
[hidden email]
http://lists.squid-cache.org/listinfo/squid-users
Reply | Threaded
Open this post in threaded view
|

Re: rock storage and max-swap-rate

reinerotto
>I believe that journal is only wirtten to, when you make change at
filesystem level, like creating or removing files.<
This is more or less correct only, in case the _default_ journal strategy
"ordered" is used.
But even then, according to the docs, "metadata" is journalled. Which also
includes timestamps.
Especially noteworthy here:  Last modification of file.  

>Since rock storage is one file, journaling only affects it when you create,
enlarge or shrink it, not otherwise.<
So this general statement is definitely not correct.




--
Sent from: http://squid-web-proxy-cache.1019090.n4.nabble.com/Squid-Users-f1019091.html
_______________________________________________
squid-users mailing list
[hidden email]
http://lists.squid-cache.org/listinfo/squid-users