Path: csiph.com!usenet.pasdenom.info!weretis.net!feeder4.news.weretis.net!nuzba.szn.dk!pnx.dk!fu-berlin.de!uni-berlin.de!individual.net!not-for-mail From: Ian Collins Newsgroups: comp.programming Subject: Re: Do integrity checks by file comparison really work? Date: Sat, 19 Jan 2013 18:36:30 +1300 Lines: 45 Message-ID: References: <50ec0b68$0$17952$4fafbaef@reader1.news.tin.it> <50f68341$0$13278$4fafbaef@reader2.news.tin.it> <3ldjf892v9a6cfbprr4qirpgchkj9sg2ev@4ax.com> Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Trace: individual.net 9XQc5+Ea+ZvUHvtk07YvdwGthx1OY/9fmS+/o0yOGeKepen/kWSNrlo1xYbMwrj4kq Cancel-Lock: sha1:I2srMId1YJuhyE9Nd1/4JSjEBiQ= User-Agent: Mozilla/5.0 (X11; SunOS i86pc; rv:17.0) Gecko/17.0 Thunderbird/17.0 In-Reply-To: Xref: csiph.com comp.programming:2865 Robert Wessel wrote: > On Sat, 19 Jan 2013 17:12:24 +1300, Ian Collins > wrote: > >> Robert Wessel wrote: >>> On Wed, 16 Jan 2013 11:38:54 +0100, Thomas B >>> wrote: >>>> >>>> You wrote: "I've never seen an OS that would share file buffers between >>>> two files like that", so I suppose this should be the same for files on >>>> the same volume. >>> >>> >>> Some OS's/filesystems can do a copy with the equivalent of a *nix hard >>> link, and then do a copy-on-write procedure if the file is ever >>> modified. In that case you may have only a single copy of the file. >>> It can't do that to you across volumes. >> >> ZFS is a good example. If you snapshot or clone a filesystem, no extra >> space is used until it (a clone) or the source are modified. >> >> ZFS also checksums its data, so there is no need to use another tool to >> validate copes. > > > That's not completely true - a copy can go bad while you're not > looking. The ZFS checksums will catch that right away when you do go > to read it (so actually comparing it to the original is theoretically > not necessary), a compare after writing a copy could add a level of > confidence to the backup. Of course nothing prevents sectors on the > backup disk from going bad immediately after you do the compare. Paranoia makes for a good sys-admin! That's one reason why ZFS has the scrub feature which reads all of the data in a pool. > Another reason to do a compare is if you're paranoid enough to not > completely trust the backup software/filesystem/I/O subsystem/disk > drive. We've all seen cases where the software and/or hardware did > peculiar things. There were a number of cases of virtual environments causing trouble with ZFS by claiming data was written to disk when it wasn't. -- Ian Collins