Les Mikesell wrote:
> That doesn't sound difficult at all. I suspect your real problem is
> that you are running a *bsd UFS filesystem with it's default sync
> metadata handling which is going to wait for the physical disk action to
> complete on every directory operation. I think there are other options
> but I haven't kept up with them. I gave up on UFS long ago when I
> needed to make an application that frequently truncated and rewrote a
> data file work on a machine that crashed frequently. The sync-metadata
> 'feature' statistically ensured that there was never any data in the
> file after recovering since the truncation was always forced to disk
> immediately but the data write was buffered so with a fast cycle the
> on-disk copy was nearly always empty.
>
> Is anyone else running a *bsd?
>
The problem is the reads, not writes. It takes long time for BackupPC to
figure out if the file should be backed up or not. Backups take very
long time even when there are few files which are backed up.
But I have to disagree, again :) When you make writes and filesystem is
mounted with 'sync' option which is default on FreeBSD then all
operations are done sync. Your program must have been doing something
between truncate and the actual write operation which caused file to be
empty for a period of time.
From FreeBSD mount manual
-> sync All I/O to the file system should be done synchronously.
-> async All I/O to the file system should be done asynchronously.
This is a dangerous flag to set, and should not be used
unless you are prepared to recreate the file system
should your system crash.
This 'feature' as you call it, exists in linux also
From Linux mount manual
-> sync All I/O to the file system should be done synchronously
-> async All I/O to the file system should be done asynchronously.
The only difference is that FreeBSD uses sync by default because they
claim(there is no point to argue if it is true or not, there are enough
threads about those if you google :) ) that it is safer while Linux uses
async. You could easily enable 'async' IO on FreeBSD to have the same
behaviour.
>>>> Perhaps, but there is a difference if they are moving 10 times or
>>>> 100000 times. Where the difference is that the possibility of
>>>> failure due to mechanical problems increases 10000 times.
>>>
>>> No, it doesn't make a lot of difference as long as the drive doesn't
>>> overheat. The head only moves so fast and it doesn't matter if it
>>> does it continuously. However, if your system has sufficient RAM, it
>>> will cache and optimize many of the things that might otherwise need
>>> an additional seek and access.
>>
>> I cant see how you can reach to this conclusion.
>
> Observation... I run hundreds of servers, many of which are 5 or more
> years old. The disk failures have had no correlation to the server
> activity.
Hard drive manufacturers disagree with you. They do consider the
duty-cycles when calculating the MTBF values.
http://www.digit-life.com/articles/storagereliability/
Thanks,
Evren
-------------------------------------------------------------------------
Take Surveys. Earn Cash. Influence the Future of IT
Join SourceForge.net's Techsay panel and you'll get the chance to share your
opinions on IT & business topics through brief surveys-and earn cash
http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV
_______________________________________________
BackupPC-users mailing list
BackupPC-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/backuppc-users
http://backuppc.sourceforge.net/
