32 lines
1.2 KiB
Plaintext
32 lines
1.2 KiB
Plaintext
MBOX-Line: From lyndon at orthanc.ca Thu Dec 27 14:16:07 2007
|
|
To: imap-protocol@u.washington.edu
|
|
From: Lyndon Nerenberg <lyndon@orthanc.ca>
|
|
Date: Fri Jun 8 12:34:41 2018
|
|
Subject: [Imap-protocol] Private FETCH items
|
|
In-Reply-To: <20071227220934.GA10658@brong.net>
|
|
References: <46CC88EE.5040500@andrew.cmu.edu>
|
|
<22D7E33A-FD12-4B76-8240-89A4690A03B6@orthanc.ca>
|
|
<20071227220934.GA10658@brong.net>
|
|
Message-ID: <CBA48E6C-5C97-4797-838D-6DC16E083644@orthanc.ca>
|
|
|
|
|
|
On 2007-Dec-27, at 15:09 , Bron Gondwana wrote:
|
|
|
|
> You're lucky if you've never seen file corruption due to bitrot on
|
|
> large
|
|
> drive arrays. We have about 30TB online at the moment and that's
|
|
> growing fairly rapidly. The research out there suggests we're
|
|
> likely to
|
|
> have a block level corruption every couple of months with the current
|
|
> level of affordable component reliability.
|
|
|
|
But that's a local hardware issue, and should be handled locally to
|
|
the host. I.e. have the IMAP server checksum the files when writing to
|
|
disk, and verify that checksum when reading the data. Doing random
|
|
checks via the IMAP protocol won't prevent you from offering corrupted
|
|
data to clients. You have the right solution, but you're applying it
|
|
at the wrong layer.
|
|
|
|
--lyndon
|
|
|