Page size?Ideal stripe size for Scalix?

[mxx]

Hi,

I'm planning to using a sas raid 10 array consisting of 4 spans just for the message store using xfs.

Does anyone have any recommendation as to what would be a good value to set the stripe size to for that array?
It would be good to know what page size Scalix uses when writing and accessing files inside the message store.

Thank you very much!

Max

Edit: last time I checked the majority of files inside ~/data are way bigger than 1MB, where's imap-cache and ofs use very small files.. but as I understand it this isn't the only factor to take into account as it doesn't tell how Scalix is accessing those files.. that's why I asked about the page size.

[smpoole7]

We'll see what others say, but here's my opinion.

The big bottleneck with a mail server is going to be your bandwidth. You can optimize your array for I/O times that resemble lightning, but if you only have a 1.5 or 3 megabit Internet service, it's not going to make a lot of difference. As each mail comes in, your server will say, "bzzt!!!" and process it in a couple of microseconds, but then it bottlenecks waiting for the next data to come in through that relatively-limited (by comparison) data pipe.

If it was me, I'd go with the default (which is 64KByte, I believe). A mail server has a lot of variables -- people receive new mail, delete old mail, one guy gets huge attachments while the next only gets an occasional, "this is mom, why don't you write?!?" In other words, don't view this as a typical database server. It isn't. Scalix has a database, but it's basically an *index* of pointers into the mail and/or a list of users. You're not going to have millions of fixed-size data records to deal with, you're going to have a mail store that grows and shrinks with usage. See what I'm saying?

But still, I say it's a smart move on the Raid, by the way. Don't know if I'd go all with Raid 10; ee have just a basic Raid 1 with two 500 Gig disks. We deliberately take a performance hit on disk I/O to do 100% mirroring. (See what I said above: your bottleneck isn't going to be disk I/O, it's going to be your Internet connection.)

But it's still worth it. That Raid has saved our bacon TWICE in the past month and a half -- we lost one drive, kept running on the second, replaced the first drive. Then the second one died, we kept running on the (new) first until we replaced the second one!

Proves what Carnegie Mellon and Google have found out in separate studies, by the way ... assuming all of the same disks, same type and same approximate age, if you lose one in a RAID array, you are almost certain to lose another one within a few weeks. I didn't believe it either until it happened to me. (Twice.)

[mxx]

Hey,

thanks for your reply.

You're absolutely right about drives failing all at once. It also happened to me, with only 2 days between the failures!!

Of course having a raid0 spanned across 4 raid 1 groups adds to the risk
Maybe it would lower the probability to first build an array without any hot spares and then after a few weeks buy as much new drives you'd need for your hot spares. Then replace some drives in the array with new ones and set the older ones as hot spares.. just an idea

The reason why I want good i/o performance besides being capped by wan speed is that about 70% of traffic occurs in the intranet.
For the intranet I have a different route to the DMZ.
It's connected via 4x 1GBit uplinks in balance-alb mode. So network performance is quite high.
Local workers who need to access big, foreign mailboxes that can't be cached locally would get much more performance that way. I'm planning to disable smart cache for everyone in the intranet anyway.

Thanks for your answer.. it's not easy to select the right sripe/chunk sizes.. but the lack of info about Scalix in this regard will push me to use the default 64k often recommended for "mail servers"..

All the best,

Max