rdiff-backup-users
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [rdiff-backup-users] The rdiff-backup poll!


From: dean gaudet
Subject: Re: [rdiff-backup-users] The rdiff-backup poll!
Date: Tue, 20 Dec 2005 21:14:21 -0800 (PST)

On Tue, 20 Dec 2005, Ben Escoto wrote:

> >>>>> dean gaudet <address@hidden>
> >>>>> wrote the following on Tue, 20 Dec 2005 14:06:16 -0800 (PST)
> >
> > i have to exclude a ~2M inode subtree on my server because its inode
> > churn is way too high for my dsl + home /backup disk to accomodate.
> > (it's the http://electricsheep.org/ screensaver central
> > server... the co-ordination of the animations is unfortunately inode
> > intensive.)
> 
> Wow, it needs 2 million files?  That seems incredibly excessive for a
> screensaver.

no... my box is the central server in a distributed rendering farm... in a 
typical day the screen saver clients will render 200k+ jpg frames for 
animations which are uploaded to my server for assembly into mpegs... the 
clients download the mpegs and display those mpegs as the screensaver.

in the temporary states of the rendering there are up to 6 inodes per 
frame... so on a typical day that's ~1M inodes destroyed and created.  
it's not the greatest system design, but the animations look cool :)  
i've been working on improving the server design.

i just don't try backing it up any more because it takes too long and has 
a lot of worst case behaviour... the animations can be regenerated should 
it ever be necessary and so i backup only the "genetic design" of the 
sheep from which all the animations are generated.

i hope to be reducing it to 3 inodes per frame soon... to improve the 
scalability of the server.  but even then i probably wouldn't be backing 
up any per-frame data... i might consider backing up the mpegs some day, 
but the main issue there is that it generates 3 to 4GB of new mpegs per 
day... and they're not kept around for very long either, and it consumes a 
lot of space as increments.

-dean




reply via email to

[Prev in Thread] Current Thread [Next in Thread]