On Sat, Jun 05, 2004 at 06:18:12PM +1000, Michael Mansour wrote: > > > At 15:20 5/28/2004, Michael Mansour wrote: > > > >Not only do I wonder if tar will respond the same way > > > >as rsync without the -S option, but I'm also wondering > > > >if backup software which use rsync to perform backups > > > >would also take this into account... > > > > > > I also wonder if there is any downside to using -S or whether it might > > > produce an undesirable result in some cases. If not, perhaps one should > > > always use it just in case? > > > > Sparse files are a boon or a bust. > > > > If you make a sparse file > > > > open(); write(byte); lseek(way-out-there); write(byte); close() > > > > you have not reserved or allocated the disk blocks > > for all the possible stuff in the middle. If you expect those > > blocks to be real and there is not enough disk space in the future > > things will bust. > > ..... > > Thanks Tom, excellent explanation. You are welcome. > We learn something everyday :) ... I'm wondering now > if those sparse files that got "un-sparsed" on the > rsync will still be valid if, for example, Azureus was > to continue downloading to them. There should be no problem. If the file was sparse (holes of null) blocks of null would be delivered on demand. In the un-sparsed situation you still get your block of nulls, this time from physical disk. In some cases a program that loads a large sparse data file will be slower because it becomes disk bandwidth IO bound. The kernel filesystem code would see a gap in a sparse file and copy a block of nulls at 'register to memory' speed into the applications data space. Such applications with BIG sparse data sets are rare. It is something to think about if you are designing a application with big sparse data and big sparse files. -- T o m M i t c h e l l /dev/null the ultimate in secure storage.
