* Frank Cusack :
> On 1/20/11 11:49 PM -0600 Stan Hoeppner wrote:
> >Frank Cusack put forth on 1/20/2011 2:30 PM:
> >>On 1/20/11 12:06 AM -0600 Stan Hoeppner wrote:
...
> Wow so you are basically an asshole as well as arrogant.
Please give it a break. Take private things offlist.
p@rick
--
Sorry all. I responded before catching up to the end of the thread.
On 1/20/11 11:49 PM -0600 Stan Hoeppner wrote:
Frank Cusack put forth on 1/20/2011 2:30 PM:
On 1/20/11 12:06 AM -0600 Stan Hoeppner wrote:
This is amusing considering XFS is hands down
the best filesystem available on any platform, including ZFS. Others
are simply ignorant and repeat what the
Jerry put forth on 1/21/2011 7:53 AM:
> Seriously, isn't it time this thread died a peaceful death. It has long
> since failed to to have any real relevance to Dovecot, except in the
> most extreme sense. It has evolved into a few testosterone poisoned
> individuals attempting to make this forum a
> In any case, I am not creating a kill filter to dispense with it.
not or now?
--
Ralf Hildebrandt
Geschäftsbereich IT | Abteilung Netzwerk
Charité - Universitätsmedizin Berlin
Campus Benjamin Franklin
Hindenburgdamm 30 | D-12203 Berlin
Tel. +49 30 450 570 155 | Fax: +49 30 450 570 96
Seriously, isn't it time this thread died a peaceful death. It has long
since failed to to have any real relevance to Dovecot, except in the
most extreme sense. It has evolved into a few testosterone poisoned
individuals attempting to make this forum a theater for some mating
ritual. If they seriou
Frank Cusack put forth on 1/20/2011 2:30 PM:
> On 1/20/11 12:06 AM -0600 Stan Hoeppner wrote:
>> This is amusing considering XFS is hands down
>> the best filesystem available on any platform, including ZFS. Others are
>> simply ignorant and repeat what they've heard without looking for current
>
On 1/20/11 12:06 AM -0600 Stan Hoeppner wrote:
This is amusing considering XFS is hands down
the best filesystem available on any platform, including ZFS. Others are
simply ignorant and repeat what they've heard without looking for current
information.
Not to be overly brusque, but that's a l
Ed W put forth on 1/20/2011 6:54 AM:
> Oh well, pleading over. Good luck and genuinely thanks to Stan for spending
> his
> valuable time here. Here's hoping you will continue to do so, but also being
> nice to the dummies?
"Dummies" isn't what this was about. Again, I misread the intent of your
On 20/01/2011 06:06, Stan Hoeppner wrote:
If you think the above is "hostile" you have lived a privileged and sheltered
life, and I envy you. :) That isn't "hostile" but a combination of losing
patience and being blunt. "Hostile" is "f--k you!". Obviously I wasn't being
"hostile".
I'm living
Ed W put forth on 1/17/2011 12:23 PM:
> On 17/01/2011 02:20, Stan Hoeppner wrote:
>> Ed W put forth on 1/16/2011 4:11 PM:
Using XFS with delayed logging mount option (requires kernel 2.6.36 or
later).
XFS has natively used delayed allocation for quite some time, coalescing
On Tue, Jan 18, 2011 at 11:44 AM, Stan Hoeppner wrote:
>> At an ISP I worked at, we did a study (just over 2 years ago) on the
>> average size of spam mail that was been delivered to the users. It
>> worked out to an average size of between 8KB and 10KB. This was based
>> on data over a period of
Warren Baker put forth on 1/18/2011 2:53 AM:
> On Monday, January 17, 2011, Stan Hoeppner wrote:
>> Cor Bosman put forth on 1/16/2011 5:34 PM:
>>> Btw, our average mailsize last we checked was 30KB. Thats a pretty good
>>> average as we're an ISP with a very wide user base. I think 4KB average i
On 1/16/11 2:10 PM -0600 Stan Hoeppner wrote:
Using XFS with delayed logging mount option (requires kernel 2.6.36 or
later).
...
Using the delayed logging feature, filesystem metadata write operations
are pushed almost entirely into RAM. Not only does this _dramatically_
decrease physical meta
On Sat, 2011-01-15 at 10:41 +, Ed W wrote:
>
> > One of the systems to fail was a firewall running off SSD.
>
> SSD or CF?
That doesn't make a lot of difference. They're all broadly similar.
There are better devices and worse devices, but they're mostly crap.
And as I said earlier, even if
On 2011-01-17 2:47 PM, Timo Sirainen wrote:
> On Mon, 2011-01-17 at 09:07 -0500, Charles Marcus wrote:
>> On 2011-01-15 9:30 AM, Charles Marcus wrote:
>>> Then, enforce a smallish per user quota (how much would depend on your
>>> particular environment, but I'm thinking something like 250 or maybe
On Mon, 2011-01-17 at 09:07 -0500, Charles Marcus wrote:
> On 2011-01-15 9:30 AM, Charles Marcus wrote:
> > Then, enforce a smallish per user quota (how much would depend on your
> > particular environment, but I'm thinking something like 250 or maybe
> > 500MB, since our users do get a lot of larg
On Thu, 2011-01-13 at 20:19 +0100, Steve wrote:
>
> I would not use MLC in a server environment. SLC has much better
> program/erase cycles per cell.
I wouldn't be overly worried about the underlying medium.
I'm more worried about the translation layer they use on top of it, to
make it pretend t
On 17/01/2011 02:20, Stan Hoeppner wrote:
Ed W put forth on 1/16/2011 4:11 PM:
Using XFS with delayed logging mount option (requires kernel 2.6.36 or later).
XFS has natively used delayed allocation for quite some time, coalescing
multiple pending writes before pushing them into the buffer cach
On 2011-01-15 9:30 AM, Charles Marcus wrote:
> Then, enforce a smallish per user quota (how much would depend on your
> particular environment, but I'm thinking something like 250 or maybe
> 500MB, since our users do get a lot of large attachments in the course
> of doing business) on their INBOX -
On Mon, 17 Jan 2011, Steve wrote:
Von: Giles Coochey
That can depend on what you clasify as SPAM. Many, 'newsletters' which
you've been 'subscribed to' by negative option web-forms are considered
SPAM by some, and those may contain PDF attachments of 500kb+
Welll I wrote about "usual" a
On 17/01/2011 14:18, Steve wrote:
On 17/01/2011 13:41, Steve wrote:
You get 500Kb+ sized spam messages? That is not usual. I have not done
any computation on my part but I remember seen last year (or so) a study
showing that spam messages are usually below 64Kb.
That can depend on what you cl
Original-Nachricht
> Datum: Mon, 17 Jan 2011 13:45:51 +0100
> Von: Giles Coochey
> An: dovecot@dovecot.org
> Betreff: Re: [Dovecot] SSD drives are really fast running Dovecot
> On 17/01/2011 13:41, Steve wrote:
> > You get 500Kb+ sized spam messages? That
On 2011-01-17 4:49 AM, Joseph Tam wrote:
> It forces users to process their Email (or at least their INBOX).
> and keeps packratting in check. Super-big INBOX quotas seem to encourage
> wasteful habits. I've helped some users clean out their mailboxes and
> was surpised at the amount of junk bein
On 17/01/2011 13:41, Steve wrote:
You get 500Kb+ sized spam messages? That is not usual. I have not done any
computation on my part but I remember seen last year (or so) a study showing
that spam messages are usually below 64Kb.
That can depend on what you clasify as SPAM. Many, 'newsletters'
Original-Nachricht
> Datum: Mon, 17 Jan 2011 11:13:19 +0100 (CET)
> Von: Maarten Bezemer
> An: Dovecot Mailing List
> Betreff: Re: [Dovecot] SSD drives are really fast running Dovecot
>
> On Mon, 17 Jan 2011, Steve wrote:
>
> > Spam does not
On Mon, 17 Jan 2011, Steve wrote:
Spam does not bump the average mail size considerably. Average spam
mails is way smaller then average normal mails. The reason for this is
very simple: Spammers need to reach as many end users as possible. And
they need to get those mails out as fastest as po
On Sat, 15 Jan 2011, Charles Marcus wrote
Doing this will also help train users in proper email management -
treating their INBOX just like they would a physical INBOX tray on their
desk. They wouldn't just let paper pile up there, why do so in their
INBOX (because they 'can')? Ie, it should be
Original-Nachricht
> Datum: Sun, 16 Jan 2011 20:33:23 -0600
> Von: Stan Hoeppner
> An: dovecot@dovecot.org
> Betreff: Re: [Dovecot] SSD drives are really fast running Dovecot
> Cor Bosman put forth on 1/16/2011 5:34 PM:
> > Btw, our average mailsize las
On 17.1.2011, at 5.16, Noel Butler wrote:
> keep peddling, its funny to watch, thankfully its in the archives and
> google for any of your new prospective employers.
You should be more worried about prospective employers finding your own mails.
I'll help by moderating your mails before they reac
On Sun, 2011-01-16 at 20:33 -0600, Stan Hoeppner wrote:
> Cor Bosman put forth on 1/16/2011 5:34 PM:
> > Btw, our average mailsize last we checked was 30KB. Thats a pretty good
> > average as we're an ISP with a very wide user base. I think 4KB average is
> > not a normal mail load.
>
> As ano
Cor Bosman put forth on 1/16/2011 5:34 PM:
> Btw, our average mailsize last we checked was 30KB. Thats a pretty good
> average as we're an ISP with a very wide user base. I think 4KB average is
> not a normal mail load.
As another OP pointed out, some ISPs apparently have to deliver a lot of sp
Ed W put forth on 1/16/2011 4:11 PM:
>
>> Using XFS with delayed logging mount option (requires kernel 2.6.36 or
>> later).
>>
>> XFS has natively used delayed allocation for quite some time, coalescing
>> multiple pending writes before pushing them into the buffer cache. This not
>> only decrea
Btw, our average mailsize last we checked was 30KB. Thats a pretty good average
as we're an ISP with a very wide user base. I think 4KB average is not a
normal mail load.
Cor
Using XFS with delayed logging mount option (requires kernel 2.6.36 or later).
XFS has natively used delayed allocation for quite some time, coalescing
multiple pending writes before pushing them into the buffer cache. This not
only decreases physical IOPS, but it also decreases filesystem fra
Timo Sirainen put forth on 1/16/2011 12:48 PM:
> On Sun, 2011-01-16 at 00:05 -0600, Stan Hoeppner wrote:
>> Using O_DIRECT with mbox files, the IOPS
>> performance can be even greater. However, I don't know if this applies to
>> Dovecot because AFAIK MMAP doesn't work well with O_DIRECT...
>> ***H
Javier de Miguel Rodríguez put forth on 1/16/2011 12:00 PM:
> What kind of "tricks" do you use to lower the number of IOPs of your
> dovecot
> servers?
Using hardware SAN RAID controllers with 'large' (2GB) write cache. The large
write cache allows for efficient use of large queue depths.
On Sun, 2011-01-16 at 00:05 -0600, Stan Hoeppner wrote:
> Using O_DIRECT with mbox files, the IOPS
> performance can be even greater. However, I don't know if this applies to
> Dovecot because AFAIK MMAP doesn't work well with O_DIRECT...
> ***Hay Timo, does/can Dovecot use Linux O_DIRECT for writ
El 13/01/11 17:01, David Woodhouse escribió:
On Wed, 2011-01-12 at 09:53 -0800, Marc Perkel wrote:
I just replaced my drives for Dovecot using Maildir format with a pair
of Solid State Drives (SSD) in a raid 0 configuration. It's really
really fast. Kind of expensive but it's like getting 20x th
> This discussion has been in the context of _storing_ user email. The
> assumption
> is that an OP is smart/talented enough to get his spam filters/appliances
> killing 99% before it reaches intermediate storage or mailboxes. Thus, in the
> context of this discussion, the average size of a spam
Am 16.01.2011 06:39, schrieb Noel Butler:
> LOL this is just s funny., watching the no no no im right you're
> wrong, give up stanley, those on many lists are aware of your trolling,
> nobody cares about your lil SOHO world, this list contains many
> different sized orgs, and like someone e
Rick Romero put forth on 1/15/2011 10:34 AM:
> Also, if your filesystem is using 4k clusters, aren't you only using 1
> random IOPS for a 4k email? It just sounds to me like if you plan
> 'smarter', anyone can avoid the excessive costs of SSD and get 'end user
> similar' performance with commodi
LOL this is just s funny., watching the no no no im right you're
wrong, give up stanley, those on many lists are aware of your trolling,
nobody cares about your lil SOHO world, this list contains many
different sized orgs, and like someone else mentione,d the 4K email size
is SO 1994, but,
Philipp Haselwarter put forth on 1/15/2011 8:32 PM:
> ,
> | More than 97% of all e-mails sent over the net are unwanted, according
> | to a Microsoft security report.[39]
> |
> | MAAWG estimates that 85% of incoming mail is "abusive email", as of the
> | second half of 2007. The sample size f
Stan Hoeppner put forth on 1/15/2011 11:03 PM:
> Sven Hartge put forth on 1/15/2011 9:29 AM:
>> Mails the average size of 4KiB would then have been at a time when
>> MIME was not yet invented, I believe. Somewhere in 1994.
>
> No. You're doing a statistical mean. You need to be doing median. T
Sven Hartge put forth on 1/15/2011 9:29 AM:
> Andrzej Adam Filip wrote:
>> Stan Hoeppner wrote:
>
>>> [...] The average size of an email worldwide today is less than 4KB,
>>> less than one typical filesystem block. [...]
>
>> Do not confuse "unix culture" of mostly plain text only email message
Brandon Davidson put forth on 1/14/2011 10:59 PM:
> You obviously don't live in the same world I do. Have you ever been part of
Not currently, no, thankfully.
> a grant approval process and seen what kinds of files are exchanged, and
I've never worked in the public sector, only private, so I've
"SH" == Stan Hoeppner writes:
SH> Andrzej Adam Filip put forth on 1/15/2011 4:02 AM:
>> Stan Hoeppner wrote:
>>> [...] The average size of an email worldwide today is less than 4KB,
>>> less than one typical filesystem block. [...]
>>
>> Do not confuse "unix culture" of mostly plain text only e
Andrzej Adam Filip put forth on 1/15/2011 4:02 AM:
> Stan Hoeppner wrote:
>> [...] The average size of an email worldwide today is less than 4KB,
>> less than one typical filesystem block. [...]
>
> Do not confuse "unix culture" of mostly plain text only email messages
> with "MS Junk" culture of
Andrzej Adam Filip wrote:
> Sven Hartge wrote:
>> Andrzej Adam Filip wrote:
>>> Stan Hoeppner wrote:
[...] The average size of an email worldwide today is less than
4KB, less than one typical filesystem block. [...]
>>
>>> Do not confuse "unix culture" of mostly plain text only email
Sven Hartge wrote:
> Andrzej Adam Filip wrote:
>> Stan Hoeppner wrote:
>
>>> [...] The average size of an email worldwide today is less than 4KB,
>>> less than one typical filesystem block. [...]
>
>> Do not confuse "unix culture" of mostly plain text only email messages
>> with "MS Junk" cultur
On Jan 15, 2011, at 6:30 AM, Charles Marcus wrote:
One thing we are looking at here (small 50+ userbase) is kind of a
'best
of both worlds' setup - using SSD's (haven't decided yet to trust a
bare
striped set or go with a 4 drive RAID10 - probably the latter so I can
sleep at night) for the
Andrzej Adam Filip wrote:
> Stan Hoeppner wrote:
>> [...] The average size of an email worldwide today is less than 4KB,
>> less than one typical filesystem block. [...]
> Do not confuse "unix culture" of mostly plain text only email messages
> with "MS Junk" culture of overblown formatting wit
Quoting Stan Hoeppner :
Rick Romero put forth on 1/14/2011 8:29 PM:
>
>> And that's assuming a platter squeezing in 1TB of data at
7200RPMs doesn't
>> get a comparable performance improvement to a higher rotational
speed on a
>> lower volume platter...
>
> Size and density are irrele
It would be nice if some of you could stop with the personal attacks.
While I agree that assuming that all users only receive 4K emails is not
realistic in most environments, neither is assuming a requirement of all
of the super-duper triple redundant hot fail-over for a mailstore with
no quota en
One of the systems to fail was a firewall running off SSD.
SSD or CF?
It would appear it's also possible to damage some flash memory by
powering off at the wrong moment? I had a router running on a nearly
new SLC flash card and it kept suffering errors every 24 hours and
perhaps it was fi
Stan Hoeppner wrote:
> [...] The average size of an email worldwide today is less than 4KB,
> less than one typical filesystem block. [...]
Do not confuse "unix culture" of mostly plain text only email messages
with "MS Junk" culture of overblown formatting with background images
company logos as
On Fri, 2011-01-14 at 21:09 -0600, Stan Hoeppner wrote:
> Brad Davidson put forth on 1/14/2011 6:25 PM:
>
> > We just bought 252TB of raw disk for about 5k users. Given, this is
> > going in to Exchange on Netapp with multi-site database replication, so
> > this cooks down to about 53TB of usable
On 1/14/11 8:59 PM, "Brandon Davidson" wrote:
> I work for central IS, so this is the first stage of a consolidated service
> offering that we anticipate may encompass all of our staff and faculty. We
> bought what we could with what we had, anticipating that usage will grow
> over time as individ
Stan,
On 1/14/11 7:09 PM, "Stan Hoeppner" wrote:
>
> The average size of an email worldwide today is less than 4KB, less than one
> typical filesystem block.
>
> 28TB / 4KB = 28,000,000,000,000 bytes / 4096 bytes = 6,835,937,500 =
> 6.8 billion emails / 5,000 users =
> 1,367,188 emails per user
Rick Romero put forth on 1/14/2011 8:29 PM:
> And that's assuming a platter squeezing in 1TB of data at 7200RPMs doesn't
> get a comparable performance improvement to a higher rotational speed on a
> lower volume platter...
Size and density are irrelevant. Higher density will allow greater str
Brad Davidson put forth on 1/14/2011 6:25 PM:
> We just bought 252TB of raw disk for about 5k users. Given, this is
> going in to Exchange on Netapp with multi-site database replication, so
> this cooks down to about 53TB of usable space with room for recovery
> databases, defragmentation, archive
Quoting Stan Hoeppner :
David Jonas put forth on 1/14/2011 2:08 PM:
>
>> Raid10 is our normal go to, but giving up half the storage in this case
>> seemed unnecessary. I was looking at SAS drives and it was getting
>> pricy. I'll work SATA into my considerations.
>
> That's because y
>> The reason is that few if any organizations actually need
> 28TB (14
>> 2TB Cavier Green drives--popular with idiots today) of mail storage
in a
> single
>> mail store. That's 50 years worth of mail storage for a 50,000
employee
>> company, assuming your employees aren't allowed porn/video
atta
On Fri, 2011-01-14 at 17:29 -0600, Stan Hoeppner wrote:
> slow drives. The reason is that few if any organizations actually need 28TB
> (14
> 2TB Cavier Green drives--popular with idiots today) of mail storage in a
> single
> mail store. That's 50 years worth of mail storage for a 50,000 emplo
David Jonas put forth on 1/14/2011 2:08 PM:
> Raid10 is our normal go to, but giving up half the storage in this case
> seemed unnecessary. I was looking at SAS drives and it was getting
> pricy. I'll work SATA into my considerations.
That's because you're using the wrong equation for determining
On 1/12/11 , Jan 12, 11:46 PM, Stan Hoeppner wrote:
> David Jonas put forth on 1/12/2011 6:37 PM:
>
>> I've been considering getting a pair of SSDs in raid1 for just the
>> dovecot indexes. The hope would be to minimize the impact of pop3 users
>> hammering the server. Proposed design is something
On Thu, 13 Jan 2011, Timo Sirainen wrote:
How do they fail? Supposedly once a cell has reached its erase-limit it
should become read-only. Maybe the failures had nothing to do with
wearing?
Hi Timo. I start seeing I/O errors on read or write. I must admit I
don't have definitive proof that
Quoting David Jonas :
I've been considering getting a pair of SSDs in raid1 for just the
dovecot indexes.
While raid-1 is better than the raid-0 of the previous poster, do you
really want to slow down your fast SDDs with software raid-1 on top of them?
The hope would be to minimize the impac
Original-Nachricht
> Datum: Thu, 13 Jan 2011 10:17:20 +0100
> Von: "Miha Vrhovnik"
> An: dovecot@dovecot.org
> Betreff: Re: [Dovecot] SSD drives are really fast running Dovecot
> >"As a sanity check - I found some data from Mtron (on
On 13.1.2011, at 19.37, Robert Brockway wrote:
> Hi Timo. Wear levelling often isn't as good as is claimed on the box. Often
> wear levelling is only across subsets of the SSD not across the entire device.
>
> I've seen several SSD drives fail in production after about 12 months of use,
> and
On Wed, 12 Jan 2011, Timo Sirainen wrote:
On 12.1.2011, at 21.15, Matt wrote:
I thought about doing this on my email server since its troubles are
mostly disk I/O saturation but I was concerned about reliability.
Have heard that after so many read/writes SSD will go bad.
There's no need to w
On Wed, 2011-01-12 at 09:53 -0800, Marc Perkel wrote:
> I just replaced my drives for Dovecot using Maildir format with a pair
> of Solid State Drives (SSD) in a raid 0 configuration. It's really
> really fast. Kind of expensive but it's like getting 20x the speed for
> 20x the price. I think th
Miha Vrhovnik put forth on 1/13/2011 3:17 AM:
>> "As a sanity check - I found some data from Mtron (one of the few SSD oems
>> who
>> do quote endurance in a way that non specialists can understand). In the data
>> sheet for their 32G product - which incidentally has 5 million cycles write
>> endu
>"As a sanity check - I found some data from Mtron (one of the few SSD oems who
>do quote endurance in a way that non specialists can understand). In the data
>sheet for their 32G product - which incidentally has 5 million cycles write
>endurance - they quote the write endurance for the disk as "gr
David Jonas put forth on 1/12/2011 6:37 PM:
> I've been considering getting a pair of SSDs in raid1 for just the
> dovecot indexes. The hope would be to minimize the impact of pop3 users
> hammering the server. Proposed design is something like 2 drives (ssd or
> platter) for OS and logs, 2 ssds f
Matt put forth on 1/12/2011 1:15 PM:
> I thought about doing this on my email server since its troubles are
> mostly disk I/O saturation but I was concerned about reliability.
> Have heard that after so many read/writes SSD will go bad. There are
> an awful lot of read/writes on an email server.
On 1/12/11 , Jan 12, 9:53 AM, Marc Perkel wrote:
> I just replaced my drives for Dovecot using Maildir format with a pair
> of Solid State Drives (SSD) in a raid 0 configuration. It's really
> really fast. Kind of expensive but it's like getting 20x the speed for
> 20x the price. I think the big ga
Marc Perkel put forth on 1/12/2011 12:18 PM:
> time sh -c "dd if=/dev/zero of=ddfile bs=8k count=200 && sync"
>
> 200+0 records in
> 200+0 records out
> 1638400 bytes (16 GB) copied, 55.403 s, 296 MB/s
>
> real1m4.738s
> user0m0.336s
> sys 0m20.199s
That's a horrible
On 12.1.2011, at 21.15, Matt wrote:
> I thought about doing this on my email server since its troubles are
> mostly disk I/O saturation but I was concerned about reliability.
> Have heard that after so many read/writes SSD will go bad.
There's no need to worry about that in any modern drives.
> I just replaced my drives for Dovecot using Maildir format with a pair of
> Solid State Drives (SSD) in a raid 0 configuration. It's really really fast.
> Kind of expensive but it's like getting 20x the speed for 20x the price. I
> think the big gain is in the 0 seek time.
I thought about doing
On 1/12/2011 9:58 AM, Rick Romero wrote:
Quoting Marc Perkel :
I just replaced my drives for Dovecot using Maildir format with a
> pair of Solid State Drives (SSD) in a raid 0 configuration. It's
> really really fast. Kind of expensive but it's like getting 20x the
> speed for 20x the price.
Quoting Marc Perkel :
I just replaced my drives for Dovecot using Maildir format with a
> pair of Solid State Drives (SSD) in a raid 0 configuration. It's
> really really fast. Kind of expensive but it's like getting 20x the
> speed for 20x the price. I think the big gain is in the 0 seek
83 matches
Mail list logo
