Thank You very much for your feedback. highly appreciated! On Sun, April 26, 2009 19:37, Arno Wagner wrote: > In principle, your loss probability on HDDs is a bit different from > what I gather you assume. > > 1. There is defective sectors. That would likely be what you are > thinking off. There is no hard data, but my impression is that > these are more tied to the device than to the number of secors on > it. I.e. the probability of a sector going bad is something > like constant_a + constant_b * number_of_sectors_on_device. > > 2. You have whole-disk losses. These seem not to depend on the > actual disk size or may even be less likely for larger (hence more > modern) drives. > > Now for your question: You lose a LUKS volume, when you lose the > LUKS header. All other errors do not amplify, i.e. a raw bad > sector just transforms into one encryoted bad sector. > > For losing the LUKS header, you actuially need to lose the salt or > other truff right in the beginning. The probability of that happening > is _less_ for larger decives, if my intuition 1. above is correct. > The second way to lose the filesystem, is by a bad sector in a > key-block, if you have only one. The same reasoning applies, however > the key-blocks are in the MB size range, i.e. damage to one of them > is something like 3 orders of magnitude more likely. > > As to the full disk-loss, that depends on how you build your large > device and how much redundancy you have. For 2.5TB, I would > recommend using RAID6 (works well in software under Linux). > > Lastly, this is a container-file, not a device. AFAIK there > is a very low file corruption risk, if you do not write the > strucutural metadata (i.e. the inode assignmet) with LINUX > filesystem, i.e. if you do not append to the file. In fact, > I have done extensive mesurements on data > in the multi-TB range with individual files in the 200MB-1GB > range, most on ext3. I bever lost a file. In addition, I do not > see any reason why the loss-probability should be a lot larger > with larger files. True, you could have an unrecoverable > bad sector right in the metadata, but the metadata is so tiny > compared to the data area, that this is still highly unlikely > for a 2.5TB file. I think full-disk loss or array-loss for > a RAID array is a lot more likely. > > On the other hand, if you split this into smaller files and > then lvm them together, you actually get more metadata and > therefore a higher risk. > > So, short answer: There are risks with this much data, but > a single file is a low-risk approach, and only > moderately more risky than using a partition. > This does however not include operator error. A file > is easier to delete than a partition and there is typically > no undelete on Linux. Backuop is, as allways, non-optional. > > What you should of course do is runn regular disk surface > scans (long SMART selftests) and filesystem chesks. > > Arno > > > > > > On Sun, Apr 26, 2009 at 12:21:04PM +0200, ingo.schmitt@xxxxxxxxxxxxxxxxx > wrote: >> Hi, >> >> is it a good idea to use a container file which is 2,5TB large? >> is there higher risk to lose data when the file is so large? >> >> I cannot use the whole partition because the dirives are managed by lvm >> and this is too complicated for me. >> >> Thx, >> Ingo >> >> >> >> >> --------------------------------------------------------------------- >> dm-crypt mailing list - http://www.saout.de/misc/dm-crypt/ >> To unsubscribe, e-mail: dm-crypt-unsubscribe@xxxxxxxx >> For additional commands, e-mail: dm-crypt-help@xxxxxxxx >> > > -- > Arno Wagner, Dr. sc. techn., Dipl. Inform., CISSP -- Email: > arno@xxxxxxxxxxx > GnuPG: ID: 1E25338F FP: 0C30 5782 9D93 F785 E79C 0296 797F 6B50 1E25 > 338F > ---- > Cuddly UI's are the manifestation of wishful thinking. -- Dylan Evans > > If it's in the news, don't worry about it. The very definition of > "news" is "something that hardly ever happens." -- Bruce Schneier > > --------------------------------------------------------------------- > dm-crypt mailing list - http://www.saout.de/misc/dm-crypt/ > To unsubscribe, e-mail: dm-crypt-unsubscribe@xxxxxxxx > For additional commands, e-mail: dm-crypt-help@xxxxxxxx > > --------------------------------------------------------------------- dm-crypt mailing list - http://www.saout.de/misc/dm-crypt/ To unsubscribe, e-mail: dm-crypt-unsubscribe@xxxxxxxx For additional commands, e-mail: dm-crypt-help@xxxxxxxx
