On 22/1/25 09:37, Jeffrey Walton wrote:
On Sat, Nov 16, 2024 at 7:22 PM Stephen Morris
wrote:
To test my hard disk performance I have run Kdiskmark and used the Real
World Performance Profile. For its sequential read performance it is showing
around 156 MB/s on my ST3000DM007-1WY1 (3TB S
On Sat, Nov 16, 2024 at 7:22 PM Stephen Morris
wrote:
>
> To test my hard disk performance I have run Kdiskmark and used the Real
> World Performance Profile. For its sequential read performance it is showing
> around 156 MB/s on my ST3000DM007-1WY1 (3TB Seagate Barracuda), which given
> th
> On 21 Nov 2024, at 13:57, John Mellor wrote:
>
> In the Disks app, select the disk, go to the 3 dots on the top right, select
> write cache and select disable. I'm unsure, but you might need to reboot as
> well. You can also do this in the CLI, but its been years since I have had
> to do
Disks in mainframe days had no onboard cache, and the O/S had to do all
that. Today that has been built into much cheaper disks. While there is
no mechanism to determine what is cached by the onboard disk memory and
what is not, there are situations where you need disk cacheing to be
disabled
Stephen Morris wrote:
> > > 40 years ago mainframe storage controllers provided functionality to
> > > control what files were loaded into the storage cache and how much of
> > > the file was loaded, I just thought hard disks had advanced enough to
> > > now provide similar functionality.
Tim:
> >
On 19/11/24 13:22, Tim wrote:
On Tue, 2024-11-19 at 08:39 +1100, Stephen Morris wrote:
40 years ago mainframe storage controllers provided functionality to
control what files were loaded into the storage cache and how much of
the file was loaded, I just thought hard disks had advanced enough to
On Mon, Nov 18, 2024 at 2:27 AM Tim via users
wrote:
> The other thing to consider with drive thrashing, that I don't recall
> seeing being mentioned in this thread is a drive with errors. If it's
> having trouble reading/writing its media, performance will be awful.
>
> At one time the standard
On Tue, 2024-11-19 at 12:52 +1030, Tim via users wrote:
> On Tue, 2024-11-19 at 08:39 +1100, Stephen Morris wrote:
> > 40 years ago mainframe storage controllers provided functionality to
> > control what files were loaded into the storage cache and how much of
> > the file was loaded, I just thoug
On Tue, 2024-11-19 at 08:39 +1100, Stephen Morris wrote:
> 40 years ago mainframe storage controllers provided functionality to
> control what files were loaded into the storage cache and how much of
> the file was loaded, I just thought hard disks had advanced enough to
> now provide similar funct
On 2024-11-17 14:32, Felix Miata wrote:
Stephen Morris composed on 2024-11-18 09:07 (UTC+1100):
For me on my hard disk its giving:
/dev/sdd:
Timing cached reads: 52114 MB in 1.99 seconds = 26165.57 MB/sec
Timing buffered disk reads: 492 MB in 3.01 seconds = 163.69 MB/sec
and on my SSD
On Mon, Nov 18, 2024 at 4:46 PM Stephen Morris
wrote:
>
> On 18/11/24 10:36, Samuel Sieb wrote:
>
> Yes, a full cache can cause performance issues, but I would expect to be able
> to play around with the caching algorithms to control what gets cached and
> what doesn't, particularly when looking
On 18/11/24 10:36, Samuel Sieb wrote:
Yes, a full cache can cause performance issues, but I would expect to
be able to play around with the caching algorithms to control what
gets cached and what doesn't, particularly when looking at sequential
vs random access, combined with disk fragmentation
On 2024-11-17 14:00, Stephen Morris wrote:
On 17/11/24 18:02, Tim wrote:
Chris Adams:
That's a misunderstanding of how things work. The SATA port speed is
just an upper-bound on transfer, but has nothing to do with how fast a
device can actually read data (similar to having a 1G network card a
Tim:
> > Because big numbers are a marketing ploy... Sure, there's *something*
> > that the SATA port can do at that speed, but it's not continuously
> > churn your data through in the way that you'd like.
Stephen Morris:
> Yes, I understand that but when the device specs specify that the
> d
Stephen Morris composed on 2024-11-18 09:07 (UTC+1100):
> For me on my hard disk its giving:
> /dev/sdd:
> Timing cached reads: 52114 MB in 1.99 seconds = 26165.57 MB/sec
> Timing buffered disk reads: 492 MB in 3.01 seconds = 163.69 MB/sec
> and on my SSD it is giving:
> /dev/sdc:
> Timing
On 17/11/24 16:02, Michael D. Setzer II wrote:
I've always hdparm -Tt to test drives.
hdparm -Tt /dev/sda
/dev/sda:
Timing cached reads: 10716 MB in 1.99 seconds = 5377.96
MB/sec
Timing buffered disk reads: 700 MB in 3.00 seconds = 232.99
MB/sec
For me on my hard disk its giving:
/dev/
On 17/11/24 18:02, Tim wrote:
Chris Adams:
That's a misunderstanding of how things work. The SATA port speed is
just an upper-bound on transfer, but has nothing to do with how fast a
device can actually read data (similar to having a 1G network card and
even Internet service doesn't mean sites
On 2024-11-17 14:52, Frank Bures wrote:
On 2024-11-17 02:02, Tim via users wrote:
And maybe you could get a RAID device which has SATA ports to the PC,
so it can spread the load internally across several drives and keep up
with a very high data speed. I've never looked to see if anyone has
ac
On 2024-11-17 02:02, Tim via users wrote:
And maybe you could get a RAID device which has SATA ports to the PC,
so it can spread the load internally across several drives and keep up
with a very high data speed. I've never looked to see if anyone has
actually done that.
Back in the early 00'
Once upon a time, Stephen Morris said:
> If that is the case why does the specs for that device under
> performance say it will support speeds of 1Gb/s, 3Gb/s and 6Gb/s.
Because that is the speed of the link between the drive and the
controller/motherboard. It's possible for an individual sector
> On 17 Nov 2024, at 04:45, Stephen Morris wrote:
>
> If that is the case why does the specs for that device under performance say
> it will support speeds of 1Gb/s, 3Gb/s and 6Gb/s.
Because that is the spec of the connectors on the motherboard.
It provides an upper bound on transfer speed, b
Chris Adams:
> > That's a misunderstanding of how things work. The SATA port speed is
> > just an upper-bound on transfer, but has nothing to do with how fast a
> > device can actually read data (similar to having a 1G network card and
> > even Internet service doesn't mean sites will serve data t
On 17/11/24 11:54, Chris Adams wrote:
Once upon a time, Stephen Morris said:
To test my hard disk performance I have run Kdiskmark and used
the Real World Performance Profile. For its sequential read
performance it is showing around 156 MB/s on my ST3000DM007-1WY1
(3TB Seagate Barracuda), w
On 17 Nov 2024 at 15:44, Stephen Morris wrote:
Date sent: Sun, 17 Nov 2024 15:44:51 +1100
Subject:Re: Fedora F41 Hard Disk Performance
To: users@lists.fedoraproject.org
From: Stephen Morris
Copies to: steve.morris...@gmail.com
Send reply to: Community support for Fedora
Hi,
To test my hard disk performance I have run Kdiskmark and used the
Real World Performance Profile. For its sequential read performance it
is showing around 156 MB/s on my ST3000DM007-1WY1 (3TB Seagate
Barracuda), which given that device support 1/3/6 Gb/s I/O speeds and
the device is p
Stephen Morris composed on 2024-11-17 11:22 (UTC+1100):
> To test my hard disk performance I have run Kdiskmark and used the
> Real World Performance Profile. For its sequential read performance it
> is showing around 156 MB/s on my ST3000DM007-1WY1 (3TB Seagate
> Barracuda),
That's typic
Once upon a time, Stephen Morris said:
> To test my hard disk performance I have run Kdiskmark and used
> the Real World Performance Profile. For its sequential read
> performance it is showing around 156 MB/s on my ST3000DM007-1WY1
> (3TB Seagate Barracuda), which given that device support 1/
27 matches
Mail list logo
