> more disk activity than on a 'normal' directory. Sorting the stat()
> > calls by inode number would help, but I doubt 'ls' is optimized for
> > such an unusual usage case (but I haven't checked, so I might be wrong).
>
> that is the job of the SCSI (and not SATA) command queuing,
> reorder the requests to optimize the head seeks... that is
> also why IDE suck so much
>
That is about 90% correct. in SATA the NCQ exists above the head
controller. The head should tend to order the data due to the NCQ
organizing the input stream better. SCSI and SAS actually have knowledge of
the head position at the same level as the command queue which makes them
more capable at such tasks. IDE is garbage, I agree.
>
> But anyway, if someone is working under RAM pressure or
> IO pressure, you have no cache, and without cache, all
> HDs/OS/filesystems will take a HUGE performance hit
>
> This is somewhat dependant on filesystem and IO Scheduler of the OS. Some
filesystems excel under IO loads (ZFS) but shrivel and die under RAM
pressure(ZFS). XFS is pretty much middle of the line while EXT3 runs very
well with limited ram but chokes under IO pressure. In linux, the CFQ
scheduler is very good under IO pressure but slows under low resource
situations while the AS scheduler is not terribly fast overall but keeps its
cool under the worst conditions.
------------------------------------------------------------------------------
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/
