Re: Squid performance - SquidFS

> No FS you can name handles the way squid works really well, due its nature
> of lots of objects coming *and going* all the time. Not even CNFS, since
> we have objects being removed from all over the store, not in batches like
> news does.

        Agreed.

> So, using one big file (or going right to a partition) should be a much
> better way to do things. This is how my patch works. You create 1 big file
> to store all objects in. Each StoreEntry has a new member called "offset"
> which is simply the byte offset for that object within the file. You want
> to read the object? Seek to "offset" and read x bytes (more than 1 read is
> generally required). And, removing an object from the store requires a
> single write of 512 bytes (if we weren't worried about crash recovery, we
> wouldn't even have to do this).

        Okay, this is generally how my design works. There is one big file
per disk partition. There is a thread responsible for IO to that partition
and it orders the reads and writes as required to optimise disk activity.
Fragementation is not an issue for my design however since it assumes all
writes/accesses are in multiple of 8K chunks, down to a minumum of 4K frags.
With a 2:1 chunk/frag size ratio, fragmentation isn't an issue right until
the disk practically is full. If we keep that last 1% free, we're happy.

> Someone pointed out that you can perform defragmentation, but that takes
> CPU time and disk I/O that might be a signifigant impact on a busy cache.
> However, I got to thinking that no cache in the world will be busy to
> capacity 24 hours a day. So what I'm thinking is that the defragmentation
> can be performed during the "off hours" when we can afford to do it.
> So, the only trick here is determining the off hours. The simpliest way
> would be to just add it to the config and let the admin set it.
> ie
> off_hours_start 1am
> off_hours_end 9am

Hmmm. I always rather disappointed when I see "off-hours" designs. That
to me just takes the easy way out and leads to problems in the future. eg.
What happens when fragmentation gets bad during the period of on-peak hours?
What then? Can you GUARANTEE that it won't? I don't think so. Same with
the delayed unlinked people talk about. Can you GUARANTEE? If the answer
is even a remote no, then the design is flawed.

> I think this would be better than defining off hours, since you could take
> advantage of a lull in the middle of the day to get some defragmenting
> done. I'm thinking there is *at least* 12 hours a day when it wouldn't
> impact response time very much if we did some defragmenting.
> On a machine that is severly overloaded, this process might fall apart.
> But then, if a machine is THAT overloaded, what the hell can you do
> anyways?

        Sorry. Don't mean to sound rude, but that is a weak approach to
the problem. Design the system such that fragmentation is not an issue,
even if it's at the cost of 5-10% disk space overall. People will always
be prepared to sacrifice 10% of space for better speed OVERALL, rather than
gain that last 10% at the chance of things going dreadfully slow. This is
even more true in caching where latecy is important.

        I want a filesystem that is capable of being driven hard 24 hours a
day non-stop, and won't fragment and runs 90-100% as fast as another solution.
I believe that can be done.

The reason why I want this is because for us, our low-peak times currently
are 12:30am to 8:30am. 6-830am is medium load, as is 12:30 to 2. So we're
talking about a 4 hour window where the disks have a decent amount of spare
capacity. I don't think you could guarantee low fragmentation in that
environment with the system you propose.

> Defragmenting can be done by either actually physically moving data, or
> maybe just releasing some objects. This could probably be decided
> semi-intelligently by examining the object in question and seeing if it
> might be a good candidate for releasing (ie if its been in the cache a
> while, and has lots of hits, we probably don't want to release it).

        Sigh. And that costs too.

        Stew.

-- 
Stewart Forster (Snr. Development Engineer)
connect.com.au pty ltd, Level 9, 114 Albert Rd, Sth Melbourne, VIC 3205, Aust.
Email: slf@connect.com.au   Phone: +61 3 9251-3684   Fax: +61 3 9251-3666