Thanx for interest.
There is no chance to change all scripts (too many customers and
thousands and thousands perl/php skripts).
I think it isn't right way compiling own perl/php libs with needed changes on
open/fopen function.
DS
On Thu, Jun 26, 2008 at 04:19:39PM -0500, Eric Sandeen wrote:
> DS wrote:
> > Hmm, but file overwrite in perl/php is slow, very slow.
>
> If you have control over your perl/php, perhaps you can change it to do
> unlink/create/write instead of truncate/write?
>
> -Eric
>
> > Which FS is best for me?
> > XFS - perl/php overwrite problem
> > EXT3 - 32000 subdirs limit
> > REISER - no future
> > JFS - ?
> >
> > DS
> >
> > On Wed, Jun 18, 2008 at 10:49:07AM -0700, Dave Chinner wrote:
> >> On Wednesday 18 June 2008 10:09 am, Eric Sandeen wrote:
> >>> After Lachlan's fix to separate on-disk and in-memory sizes, and only
> >>> update on-disk when data is on-disk
> >>> (http://www.linux.sgi.com/archives/xfs/2007-05/msg00020.html) is the
> >>> XFS_ITRUNCATED flag / flush-on-close-after-truncate still needed?
> >> Yes, because waiting 30s before writing back /etc/fstab after it
> >> has been modified will result in lots of bug reports of /etc/fstab
> >> being zero length after a crash instead of being full of NULLs.
> >> We have had very few reports of zero length files or files with
> >> NULLs since this change was made (regardless of the file size
> >> update ordering changes). i.e. if we remove this code then the
> >> common case where NULL files occurred will return - only this
> >> time as zero length files.
> >>
> >> Cheers,
> >>
> >> Dave.
> >>
> >>
> >
> >
>
|