[OpenAFS-devel] AFS + GFS = crazy?

[John Hascall]

> dumb users, fire, sprinklers, hurricane, hot-swap drives evolving and 
> growing legs, servers evolving and growing legs....

* dumb users
   + GFS implements lazy delete, a deleted chunk is just renamed
     and you can schedule when you go through and reclaim this
     space.  In our case we only keep our normal backups for
     a 28-day cycle.  So if you only cleaned up deleted chunks
     after they'd stewed for that long, that seems mostly
     equivalent.  Also, we've trained our users with our mantra
     "Our backups are for us, if you want your own, be our guest"
     (this may not work for you).

   + I don't see that GFS prevents against mistakenly overwriting
     (in-place) your data with garbage (but you have the AFS
     protection of the nightly .backup volume of course).

* fire, sprinklers, hurricane, theft
   + if this happened simultaneously to all three (or however many
     you configured) of your data centers, then it might just be
     time to seek another line of work :)

And, of course, nothing in this scheme would prevent you from making
backups if you wanted -- and you'd still get the uptime advantage.

John

     
> John Hascall wrote, On 8/2/2006 11:42 AM:
> >> In message <200608021454.JAA06668@malison.ait.iastate.edu>,
> > John Hascall writes:
> >>> The idea behind GFS is that these file chunks are
> >>> stored on multiple (N, usually 3) chunkservers -- so
> >>> you can lose N-1 of them and still be up and have
> >>> your data.  And the chunkservers could even be
> > 
> >> and yet people still backup raid filesystems.  there are certain
> >> critical failures that cannot be solved with this solution.
> > 
> > And which critical failures would that be?
> > 
> > 
> > John
> > _______________________________________________
> > OpenAFS-devel mailing list
> > OpenAFS-devel@openafs.org
> > https://lists.openafs.org/mailman/listinfo/openafs-devel
> > 
> 
> 
> _______________________________________________
> OpenAFS-devel mailing list
> OpenAFS-devel@openafs.org
> https://lists.openafs.org/mailman/listinfo/openafs-devel
>