Path: csiph.com!v102.xanadu-bbs.net!xanadu-bbs.net!nntp.club.cc.cmu.edu!micro-heart-of-gold.mit.edu!bloom-beacon.mit.edu!bloom-beacon.mit.edu!panix!not-for-mail From: cross@spitfire.i.gajendra.net (Dan Cross) Newsgroups: comp.lang.c Subject: Re: [sot] file times / file metadata Date: Wed, 29 Nov 2017 21:01:32 +0000 (UTC) Organization: PANIX Public Access Internet and UNIX, NYC Lines: 47 Message-ID: References: <5a91718b-b272-4cdf-adfd-8f6777851b23@googlegroups.com> NNTP-Posting-Host: spitfire.i.gajendra.net X-Trace: reader2.panix.com 1511989292 4152 166.84.136.80 (29 Nov 2017 21:01:32 GMT) X-Complaints-To: abuse@panix.com NNTP-Posting-Date: Wed, 29 Nov 2017 21:01:32 +0000 (UTC) X-Newsreader: trn 4.0-test77 (Sep 1, 2010) Originator: cross@spitfire.i.gajendra.net (Dan Cross) Xref: csiph.com comp.lang.c:123625 In article , David Brown wrote: >I think many people have a concept that a "copy" must in some way be >/physically/ independent of the original. In reality, copies are often >just logical copies - they act as though they are independent in storage >somewhere, but they might not be. They might be CoW copies, or stored >on something with deduplication. Even if they are supposedly >independent copies on different disk sectors, they might be on the same >physical disk or the same file system, and therefore not independent. >And you can go the other way - a file may appear to be a single logical >file, but have multiple physical copies (such as on a RAID system). Yes, that's the intuition. I suspect that Stuckle thinks of a "copy" as something one puts on a 5.25" floppy disk and then trades to the kid down the street for an old copy of Sports Illustrated. >To me, a "copy" is a logical operation. It means that when everything >is working as it should - no disk failures, server room fires, >filesystem corruption, human error - you have two logically independent >versions of the file or object. If you want something that protects >your data against one or more type of failure, it is a "backup". Yes; I agree. >> This came up when Plan 9 moved the filesystem to the Venti >> storage server. Venti uses content-addressible storage: blocks >> are hashed using a cryptographically-secure hashing algorithm, >> and a mapping from hash to block is kept in an index volume. >> When writing to the store, an attempt is made to look up the >> block's hash in the index; if an entry already exists, one >> assumes the block data is already present and returns success. >> Otherwise, a block is allocated, the data are written to the >> newly-allocated block, and the (hash, block address) pair is >> added to the index. > >That is probably quite a space-efficient way to store things, perhaps at >some cost in speed. Indeed. However, the file server was a dedicated machine on the network, and it was found that it could still saturate the network interface. Furthermore, there was a write-cache placed in front of Venti to amortize the cost of transient storage. >> [snip] - Dan C.