SCIENTIFIC-LINUX-USERS Archives

October 2006

SCIENTIFIC-LINUX-USERS@LISTSERV.FNAL.GOV

Options: Use Monospaced Font
Show Text Part by Default
Show All Mail Headers

Message: [<< First] [< Prev] [Next >] [Last >>]
Topic: [<< First] [< Prev] [Next >] [Last >>]
Author: [<< First] [< Prev] [Next >] [Last >>]

Print Reply
Subject:
From:
Miles O'Neal <[log in to unmask]>
Reply To:
Miles O'Neal <[log in to unmask]>
Date:
Thu, 5 Oct 2006 21:17:50 -0500
Content-Type:
text/plain
Parts/Attachments:
text/plain (40 lines)
Jon Peatfield said...
|
|I'm sure that this didn't used to happen (well it doesn't on SL3)...

Yikes.  Never seen that behavior before.
It does explain some of the discrepancy
we've seen when copying files to our tier
two storage (PC RAID farms running SL4).

|On hilus I've got ext3 on LVM2 on a plain (IDE) disk, while on
|cingulum it is ext3 on LVM2 on an external SCSI raid device (not that
|that should matter).  I get the same behaviour with 

with????

I think we lost a line there...

It gets more interesting.

At work we have a system running vanilla SL4
with ext3 (no LVM or RAID) for everything except
the NFS served filesystems which is are XFS directly
on top of hardware RAID.  On both types of filesystems
I see what I would normally expect, the behavior you
observed on SL3.

On a system at home, made from the same set of SL4
images, testing on /tmp (ext3, no LVM or RAID) I
get the SL4 behavior you observed on.

The system at work uses SATA 300GB drives; the
system at home uses an older 40GB IDE drive.  I
would not expect filesystem behavior to care about
underlying drivers such as this.

IOW, it's not necessarily consistent across SL4
ext3 filesystems, and it doesn't depend on LVM.

-Miles

ATOM RSS1 RSS2