On Wednesday, July 18, 2012 03:31:53 PM Les Mikesell wrote:
Sure, everything can break and most will sometime, but does this
happen often enough that you'd want to slow down all of your network
disk writes by an order of magnitude on the odd chance that some app
really cares about a random
On Thu, Jul 19, 2012 at 12:06 PM, Lamar Owen lo...@pari.edu wrote:
On Wednesday, July 18, 2012 03:31:53 PM Les Mikesell wrote:
Sure, everything can break and most will sometime, but does this
happen often enough that you'd want to slow down all of your network
disk writes by an order of
On Tuesday, July 17, 2012 12:28:00 PM Les Mikesell wrote:
But the thing with the spinning disks is the thing that will go down.
Not much reason for a network to break - at least since people stopped
using thin coax.
Just a few days ago I watched a facility's switched network go basically
On 07/19/2012 06:31 AM, Lamar Owen wrote:
On Tuesday, July 17, 2012 12:28:00 PM Les Mikesell wrote:
But the thing with the spinning disks is the thing that will go down.
Not much reason for a network to break - at least since people stopped
using thin coax.
Just a few days ago I watched a
On Wed, Jul 18, 2012 at 1:31 PM, Lamar Owen lo...@pari.edu wrote:
On Tuesday, July 17, 2012 12:28:00 PM Les Mikesell wrote:
But the thing with the spinning disks is the thing that will go down.
Not much reason for a network to break - at least since people stopped
using thin coax.
Just a few
On 07/13/2012 07:40 AM, Les Mikesell wrote:
On Fri, Jul 13, 2012 at 7:12 AM, mark m.r...@5-cent.us wrote:
*After* I test further, I think it's up to my manager and our users to
decide if it's worth it to go with less secure - this is a real issue,
since some of their jobs run days, and one or
On Tue, Jul 17, 2012 at 4:33 AM, Johnny Hughes joh...@centos.org wrote:
I always wondered why the default for nfs was ever sync in the first
place. Why shouldn't it be the same as local use of the filesystem?
The few things that care should be doing fsync's at the right places
anyway.
Les Mikesell wrote:
On Tue, Jul 17, 2012 at 4:33 AM, Johnny Hughes joh...@centos.org wrote:
I always wondered why the default for nfs was ever sync in the first
place. Why shouldn't it be the same as local use of the filesystem?
The few things that care should be doing fsync's at the right
On Tue, Jul 17, 2012 at 8:27 AM, m.r...@5-cent.us wrote:
I always wondered why the default for nfs was ever sync in the first
place. Why shouldn't it be the same as local use of the filesystem?
The few things that care should be doing fsync's at the right places
anyway.
Well, the reason
On Wed, July 11, 2012 00:21, Kahlil Hodgson wrote:
If you are just using the Red Hat bugzilla that might be your problem.
I've heard a rumour that Red Hat doesn't really monitor that channel,
giving preference to issues raised though their customer portal. That
does makes _some_ commercial
Am 11.07.2012 00:58, schrieb Gé Weijers:
It may not be a bug, it may be that RHEL 6.x implements I/O barriers
correctly, which slows things down but keeps you from losing data
Which is of course no excuse for not even responding to a support
request. It's not a bug, it's a feature may not
On 07/12/12 06:41, Colin Simpson wrote:
I have tried the async option and that reverts to being as fast as
previously.
So I guess the choice is use the less safe async and get file creation
being quick or live with the slow down until a potentially new protocol
extension appears to help with
On Fri, Jul 13, 2012 at 7:12 AM, mark m.r...@5-cent.us wrote:
*After* I test further, I think it's up to my manager and our users to
decide if it's worth it to go with less secure - this is a real issue,
since some of their jobs run days, and one or two weeks, on an HBS* or a
good sized
I have tried the async option and that reverts to being as fast as
previously.
So I guess the choice is use the less safe async and get file creation
being quick or live with the slow down until a potentially new protocol
extension appears to help with this.
Colin
On Wed, 2012-07-11 at 15:16
We have this issue.
I have a support call open with Red Hat about it. Bug reports will only
really forcibly get actioned if you open a support call and point at the
bug report.
I also have this issue though much much worse on Fedora (using BTRFS),
which will surely have to be fixed before BTRFS
On Wed, Jul 11, 2012 at 11:29 AM, Colin Simpson
colin.simp...@iongeo.com wrote:
But think yourself lucky, BTRFS on Fedora 16 was much worse. This was
the time it took me to untar a vlc tarball.
F16 to RHEL5 - 0m 28.170s
F16 to F16 ext4 - 4m 12.450s
F16 to F16 btrfs - 14m 31.252s
A quick
This is likely to be a bug in RHEL5 rather than one in RHEL6. RHEL5
(kernel 2.6.18) does not always guarantee that the disk cache is
flushed before 'fsync' returns. This is especially true if you use
software RAID and/or LVM. You may be able to get the old performance
back by disabling I/O
Gé Weijers wrote:
This is likely to be a bug in RHEL5 rather than one in RHEL6. RHEL5
(kernel 2.6.18) does not always guarantee that the disk cache is
flushed before 'fsync' returns. This is especially true if you use
software RAID and/or LVM. You may be able to get the old performance
back
- Original Message -
On Wed, Jul 11, 2012 at 11:29 AM, Colin Simpson
colin.simp...@iongeo.com wrote:
But think yourself lucky, BTRFS on Fedora 16 was much worse. This
was
the time it took me to untar a vlc tarball.
F16 to RHEL5 - 0m 28.170s
F16 to F16 ext4 - 4m 12.450s
It may not be a bug, it may be that RHEL 6.x implements I/O barriers
correctly, which slows things down but keeps you from losing data
On Tue, Jul 10, 2012 at 7:18 AM, m.r...@5-cent.us wrote:
Thought I'd post this here, too - I emailed it to the redhat list, and
that's pretty moribund,
On 11/07/12 00:18, m.r...@5-cent.us wrote:
For any redhatters on the list, I'm going to be reopening this bug today.
I am also VERY unhappy with Redhat. I filed the bug months ago, and it was
*never* assigned - no one apparently even looked at it. It's a
show-stopper for us, since it hits us
21 matches
Mail list logo
