There have been several threads lately about storage issues so I figured a quick refresher on how unix like systems store files would shed some light.

When you make a file on a unix system (eg Linux, FreeBSD, solaris etc)  what actually happens is the system allocates an inode (index node) on the disk to represent the file.   The inode contains the info about how big the file is and where the actual blocks are on disk.  The system also creates a directory entry containing the name of the file and the number of the inode for the file (plus some other stuff that's not relevant here.)

One of the really neat things about unix file system is more than one directory entry can refer to the same inode.   This is known as a hard link.   You end up with two file names both pointing at the same data.   When you delete a file you remove the directory entry that points to the inode.    If another directory entry also points to that inode nothing else happens.   When the last entry that points to the inode is removed the inode itself is cleared and the disk space used becomes free.

BackupPC makes very heavy use of this.  When a backup happens the file data is stored and an inode allocated for it then two directory entries are created that point to it.   One is in the directory for the machine it came from  ./pc/machine/nnn/ whatever.  The other is in the pool (or cpool if you are using compression).  Both point to the same inode and same blocks of data on disk.  When you do another backup if the same file shows up another link is created for another directory entry to the existing inode.   This is why new backups don't take much disk, mostly they just point to existing files that haven't changed.

When a backup goes away (because you deleted the machine or because it ages out) the files gets deleted from the individual pc's directory.    This doesn't actually free any disk space because the inode is still referenced by the pool and any other backups that have that file.   Eventually the last backup that references a file goes away.   When that happens the only reference to the file is in the pool.  Once a day BackupPC looks for files in the pool that only have one reference (ie they are not pointed to by any backups just the one reference from the pool) when it finds one it deletes it from the pool which frees the inode (because this was the last reference to the inode) and so frees the disk space.

This is why you can't use an SMB mount as a backuppc directory - it doesn't support multiple links to the same file.  It's also why you can't split the backuppc pool over multiple filesystems - you need to be able to point to the same blocks on disk and you can only do that for inodes in the same filesystem.

John
-------------------------------------------------------------------------
SF.Net email is sponsored by:
Check out the new SourceForge.net Marketplace.
It's the best place to buy or sell services
for just about anything Open Source.
http://ad.doubleclick.net/clk;164216239;13503038;w?http://sf.net/marketplace
_______________________________________________
BackupPC-users mailing list
[email protected]
List:    https://lists.sourceforge.net/lists/listinfo/backuppc-users
Wiki:    http://backuppc.wiki.sourceforge.net
Project: http://backuppc.sourceforge.net/

Reply via email to