On Saturday 17 January 2009 05:04:37 Daniel Kinzler wrote: > Bryan Tong Minh schrieb: > > On Sat, Jan 17, 2009 at 10:30 AM, Daniel Kinzler <[email protected]> > > > > wrote: > >> Tripling space requirements seems a bit of overkill. Maybe there's a > >> smarter solution. Ideas? > > > > ZFS snapshots? > > Hm, to quote the relevant section from wikipedia: > > An advantage of copy-on-write is that when ZFS writes new data, the > > blocks containing the old data can be retained, allowing a snapshot > > version of the file system to be maintained. ZFS snapshots are created > > very quickly, since all the data composing the snapshot is already > > stored; they are also space efficient, since any unchanged data is shared > > among the file system and its snapshots. > > > > Writeable snapshots ("clones") can also be created, resulting in two > > independent file systems that share a set of blocks. As changes are made > > to any of the clone file systems, new data blocks are created to reflect > > those changes, but any unchanged blocks continue to be shared, no matter > > how many clones exist. > > So... this means we can have the two-backup-stages solution i suggested, > without wasting space, because the unchanged data is shared by between > tween the copies? That would be perfect! > > -- daniel > > _______________________________________________ > Toolserver-l mailing list > [email protected] > https://lists.wikimedia.org/mailman/listinfo/toolserver-l
Actually it would be n-backup-stages. Snapshots need never be deleted. You can have millions of them and they don't use up much space at all ... _______________________________________________ Toolserver-l mailing list [email protected] https://lists.wikimedia.org/mailman/listinfo/toolserver-l
