Christian Völker wrote:

>> With backuppc the issue is not so much fragmentation within a file as 
>> the distance between the directory entry, the inode, and the file 
>> content.  When creating a new file, filesystems generally attempt to 
>> allocate these close to each other, but when you link an existing file 
>> into a new directory, that obviously can't be done so you end up with a 
>> lot of long seeks when you try to traverse directories picking up the 
>> inode info.
> Makes sense to me. Is there any FS which would be recommended for best
> performance?
> 
> Thanks for hints...

Starting completely from scratch I'd probably try OpenSolaris/zfs and 
use its snapshot send/receive for offsite copies.  With Linux, probably 
xfs on a 64-bit version.  These are based on reading about their 
features, not actual testing, though.  Realistically, if you are going 
to mostly fill a drive with data, you can expect the head to have to 
move around a lot to access it regardless of any magic in the filesystem 
- and moving the head is still a slow operation that makes everything 
else wait.

By the way, I've seen some reports that RHEL 5.4 (in beta now) includes 
support for xfs - so it will probably also be in  the stock CentOS 
kernel soon.

-- 
   Les Mikesell
    lesmikesell AT gmail DOT com



------------------------------------------------------------------------------
Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day 
trial. Simplify your report design, integration and deployment - and focus on 
what you do best, core application coding. Discover what's new with 
Crystal Reports now.  http://p.sf.net/sfu/bobj-july
_______________________________________________
BackupPC-users mailing list
BackupPC-users AT lists.sourceforge DOT net
List:    https://lists.sourceforge.net/lists/listinfo/backuppc-users
Wiki:    http://backuppc.wiki.sourceforge.net
Project: http://backuppc.sourceforge.net/