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
lesmikes...@gmail.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@lists.sourceforge.net
List: https://lists.sourceforge.net/lists/listinfo/backuppc-users
Wiki: http://backuppc.wiki.sourceforge.net
Project: http://backuppc.sourceforge.net/
