Messages in this thread | | | Date | Thu, 18 Jul 2002 11:32:26 +0200 | From | Matthias Andree <> | Subject | Re: [ANNOUNCE] Ext3 vs Reiserfs benchmarks |
| |
On Wed, 17 Jul 2002, bill davidsen wrote:
> In article <20020716125301.GI4576@merlin.emma.line.org>, > Matthias Andree <matthias.andree@stud.uni-dortmund.de> wrote: > > | dsmc fstat()s the file it is currently reading regularly and retries the > | dump as the changes, and gives up if it is updated too often. Not sure > | about the server side, and certainly not a useful option for sequential > | devices that you directly write on. Looks like a cache for the biggest > | file is necessary. > > Which doesn't address the issue of data in files A, B and C, with > indices in X and Y. This only works if you flush and freeze all the > files at one time, making a perfect backup of one at a time results in > corruption if the database is busy.
Right, but this would have to be taken up with Tivoli "do snapshot as dsmc starts, backup from snapshot and discard snapshot on exit"
> My favorite example is usenet news on INN, a bunch of circular spools, a > linear history with two index files, 30-40k overview files, and all of > it changing with perhaps 3.5MB/sec data and 20-50/sec index writes. Far > better done with an application backup!
In that case, when you are restoring from backups, you can also regenerate index files (at least with tradspool, I never looked at the "News in Dosen" aggregated spools like CNFS or whatever). It's really hard if you have .dir/.pag style dbm data bases that don't mirror some other single-file format. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
| |