Hi guys - I'm really looking forward to 5.3 for the potential of ext4. I am moving/copying image files lately 8G file and it is slow. I am hoping that ext4 really speeds that up.
My question is: will we be able to boot ext4 file systems? Will the boot partition still be ext3 and then have to mount the ext4 filesystem? I did not see mention of it in the release notes.
Thanks,
Jerry
On Tue, 2009-01-20 at 20:33 -0500, Jerry Geis wrote:
Will the boot partition still be ext3 and then have to mount the ext4 filesystem?
Yes, but you wouldn't gain much by making /boot ext4.
On Tue, Jan 20, 2009 at 6:33 PM, Jerry Geis geisj@pagestation.com wrote:
Hi guys - I'm really looking forward to 5.3 for the potential of ext4. I am moving/copying image files lately 8G file and it is slow. I am hoping that ext4 really speeds that up.
I don't think it will speed things up much. 8GB files are mostly hardware throughput and ext3/4 will actually be slower because the journalling etc are to make it more robust but at a speed cost. You would probably see better speed by going to ext2.
Hi;
Do you test in other file system? Like xfs or jfs? You can use the "time" command to get the exate time: # time cp /pathsource/file8g /pathdest/
Post here yours results.
[]s ________________________________________________ Renato de Oliveira Diogo
Bacharel em Ciência da Computação UNESP - Bauru
LPIC1 - Linux Professional Institute Certification - Nível 1
renato.diogo@gmail.com renato.diogo@yahoo.com.br
On Wed, Jan 21, 2009 at 02:11, Stephen John Smoogen smooge@gmail.comwrote:
On Tue, Jan 20, 2009 at 6:33 PM, Jerry Geis geisj@pagestation.com wrote:
Hi guys - I'm really looking forward to 5.3 for the potential of ext4. I am moving/copying image files lately 8G file and it is slow. I am hoping that ext4 really speeds that up.
I don't think it will speed things up much. 8GB files are mostly hardware throughput and ext3/4 will actually be slower because the journalling etc are to make it more robust but at a speed cost. You would probably see better speed by going to ext2.
-- Stephen J Smoogen. -- BSD/GNU/Linux How far that little candle throws his beams! So shines a good deed in a naughty world. = Shakespeare. "The Merchant of Venice" _______________________________________________ CentOS mailing list CentOS@centos.org http://lists.centos.org/mailman/listinfo/centos
Renato de Oliveira Diogo wrote:
Hi;
Do you test in other file system? Like xfs or jfs? You can use the "time" command to get the exate time: # time cp /pathsource/file8g /pathdest/
Post here yours results.
I like to use rsync with --progress so it shows realtime updates on the status of the copy when testing performance like that.
But I agree that the file system likely will not have a noticeable overhead with regards to copy performance on single 8GB files, now 10,000 files that take up 8GB of space I can see a file system having a performance impact.
nate
On Wednesday 21 January 2009, nate wrote:
Renato de Oliveira Diogo wrote:
Hi;
Do you test in other file system? Like xfs or jfs? You can use the "time" command to get the exate time: # time cp /pathsource/file8g /pathdest/
Post here yours results.
I like to use rsync with --progress so it shows realtime updates on the status of the copy when testing performance like that.
But I agree that the file system likely will not have a noticeable overhead with regards to copy performance on single 8GB files, now 10,000 files that take up 8GB of space I can see a file system having a performance impact.
I disagree. On most raid-controllers we use XFS has a significant advantage over Ext3 when it comes to large sequential writes. Ext3 gets nowhere near the bare metal performance.
So, in short, I think it will be interesting to see how Ext4 performs for this.
/Peter
Peter Kjellstrom wrote:
I disagree. On most raid-controllers we use XFS has a significant advantage over Ext3 when it comes to large sequential writes. Ext3 gets nowhere near the bare metal performance.
So, in short, I think it will be interesting to see how Ext4 performs for this.
Exactly. There are differences between file systems even when using very large files sequentially. I did benchmarks on various controllers and my experience was the same: the file system does matter.
On Tue, Jan 20, 2009 at 9:11 PM, Stephen John Smoogen smooge@gmail.com wrote:
On Tue, Jan 20, 2009 at 6:33 PM, Jerry Geis geisj@pagestation.com wrote:
Hi guys - I'm really looking forward to 5.3 for the potential of ext4. I am moving/copying image files lately 8G file and it is slow. I am hoping that ext4 really speeds that up.
I don't think it will speed things up much. 8GB files are mostly hardware throughput and ext3/4 will actually be slower because the journalling etc are to make it more robust but at a speed cost. You would probably see better speed by going to ext2.
I make it a habit of eating my own words if I screw up. If the results seen on Ubuntu by one test hold up, it might have a large increase in large writes (but nothing in large reads).
http://www.phoronix.com/scan.php?page=article&item=ubuntu_ext4&num=1
"Real World Benchmarks Of The EXT4 File-System"
http://www.phoronix.com/scan.php?page=article&item=ext4_benchmarks&n...
Stephen John Smoogen wrote:
Hi guys - I'm really looking forward to 5.3 for the potential of ext4. I am moving/copying image files lately 8G file and it is slow. I am hoping that ext4 really speeds that up.
I don't think it will speed things up much. 8GB files are mostly hardware throughput and ext3/4 will actually be slower because the journalling etc are to make it more robust but at a speed cost. You would probably see better speed by going to ext2.
I make it a habit of eating my own words if I screw up. If the results seen on Ubuntu by one test hold up, it might have a large increase in large writes (but nothing in large reads).
http://www.phoronix.com/scan.php?page=article&item=ubuntu_ext4&num=1
Has anything fixed fsync so it works as intended on a single file without waiting for the whole filesystem metatdata to be written?
On Friday 23 January 2009, Stephen John Smoogen wrote:
On Tue, Jan 20, 2009 at 9:11 PM, Stephen John Smoogen smooge@gmail.com
wrote:
On Tue, Jan 20, 2009 at 6:33 PM, Jerry Geis geisj@pagestation.com wrote:
Hi guys - I'm really looking forward to 5.3 for the potential of ext4. I am moving/copying image files lately 8G file and it is slow. I am hoping that ext4 really speeds that up.
I don't think it will speed things up much. 8GB files are mostly hardware throughput and ext3/4 will actually be slower because the journalling etc are to make it more robust but at a speed cost. You would probably see better speed by going to ext2.
I make it a habit of eating my own words if I screw up. If the results seen on Ubuntu by one test hold up, it might have a large increase in large writes
In my experience write performance for different filesystems is very dependant on the type of hardware. I have raid controllers where the difference between Ext3 and XFS is ~20% and I have those where it is 120%...
(but nothing in large reads).
Read (single thread seq.) is often limited by having a too low read ahead setting. "blockdev --setra 8192" can often push it up to bare metal speed for both Ext3 and XFS. It's important to note that this may not be very optimal for your typical I/O mix (non single thread, non seq.).
/Peter
Stephen John Smoogen wrote:
I make it a habit of eating my own words if I screw up. If the results seen on Ubuntu by one test hold up, it might have a large increase in large writes (but nothing in large reads).
http://www.phoronix.com/scan.php?page=article&item=ubuntu_ext4&num=1
Right, so - Ext4 faster than Ext2? Not surprising. The on-disk format has changed. There's less fragmentation. There are all sorts of clever things included in the new FS. So, yes, it does more work with the disk, but in a much more intelligent way.
I like the stability of Ext3, but in terms of speed it's not the sharpest lightbulb in the toolshed. And after many years of using Linux, I'm not even buying the myth that "Linux doesn't need a FS defragmenter." That's just not true. It does get fragmented, and due to that it does get slower.
Ext4 is a welcome improvement. The upcoming btrfs perhaps even more so.
Quoting Florin Andrei florin@andrei.myip.org:
I like the stability of Ext3, but in terms of speed it's not the sharpest lightbulb in the toolshed.
Isn't that supposed to be "not the fastest lawnmower in the toolshed" ?
on 1-23-2009 1:19 PM Ashley M. Kirchner spake the following:
Quoting Florin Andrei florin@andrei.myip.org:
I like the stability of Ext3, but in terms of speed it's not the sharpest lightbulb in the toolshed.
Isn't that supposed to be "not the fastest lawnmower in the toolshed" ?
Or " the sharpest crayon in the box".
Sounds like a Biff'ism http://en.wikipedia.org/wiki/Biff_Tannen
Scott Silva wrote:
on 1-23-2009 1:19 PM Ashley M. Kirchner spake the following:
Quoting Florin Andrei florin@andrei.myip.org:
I like the stability of Ext3, but in terms of speed it's not the sharpest lightbulb in the toolshed.
Isn't that supposed to be "not the fastest lawnmower in the toolshed" ?
Or " the sharpest crayon in the box".
Sounds like a Biff'ism http://en.wikipedia.org/wiki/Biff_Tannen
Well, "fastest knife in the chandelier" didn't sound so good, so...
On Fri, 23 Jan 2009, Florin Andrei wrote:
Stephen John Smoogen wrote:
I make it a habit of eating my own words if I screw up. If the results seen on Ubuntu by one test hold up, it might have a large increase in large writes (but nothing in large reads).
http://www.phoronix.com/scan.php?page=article&item=ubuntu_ext4&num=1
Right, so - Ext4 faster than Ext2? Not surprising. The on-disk format has changed. There's less fragmentation. There are all sorts of clever things included in the new FS. So, yes, it does more work with the disk, but in a much more intelligent way.
Fragmentation is good for SSD's. You get better performance on random I/O than sequential I/O.
On CentOS version 4 I had to re-compile the kernel in order to add more serial ports I needed for Halifax. Was version 5 changed so that you can add more serial ports, I need up to 24 additional, without a kernel re-compile?
Thanks John Warren
-----Original Message----- From: centos-bounces@centos.org [mailto:centos-bounces@centos.org] On Behalf Of John Warren Sent: Thursday, February 12, 2009 4:47 PM To: CentOS mailing list Subject: [CentOS] Serial channels on version 5
On CentOS version 4 I had to re-compile the kernel in order to add more serial ports I needed for Halifax. Was version 5 changed so that you can add more serial ports, I need up to 24 additional, without a kernel re-compile?
---- Well looking at this I would say yes...
[root@twilight boot]# cat config-2.6.18-92.1.18.el5 | grep CONFIG_SERIAL CONFIG_SERIAL_NONSTANDARD=y CONFIG_SERIAL_8250=y # Linked IN? CONFIG_SERIAL_8250_CONSOLE=y CONFIG_SERIAL_8250_PCI=y CONFIG_SERIAL_8250_PNP=y CONFIG_SERIAL_8250_CS=m CONFIG_SERIAL_8250_NR_UARTS=32 # Up to 32 Ports if Needed CONFIG_SERIAL_8250_RUNTIME_UARTS=4 # Four on Boot time CONFIG_SERIAL_8250_EXTENDED=y CONFIG_SERIAL_8250_MANY_PORTS=y # Set to "y" CONFIG_SERIAL_8250_SHARE_IRQ=y CONFIG_SERIAL_8250_DETECT_IRQ=y CONFIG_SERIAL_8250_RSA=y CONFIG_SERIAL_CORE=y CONFIG_SERIAL_CORE_CONSOLE=y CONFIG_SERIAL_JSM=m
JohnStanley
-
Ashley M. Kirchner -
Dag Wieers -
Florin Andrei -
Ignacio Vazquez-Abrams -
Jerry Geis -
John -
John Warren -
Les Mikesell -
Miguel Medalha -
nate -
Paul Heinlein -
Peter Kjellstrom -
Renato de Oliveira Diogo -
Scott Silva -
Stephen John Smoogen