Am 09.03.2012 06:19, schrieb Chris Murphy:
The one anomaly is the 3rd ext4 copy.
Maybe it wasn't quite done writing out the 2nd copy?
this usually happens without explicit sync
Compared to btrfs and XFS, there was a lot of intermittent disk activity
well after the copy had finished -
On Mar 9, 2012, at 12:30 AM, Matthias Runge wrote:
if your file system places data inefficiently on disk/storage, you want
to measure this, too. If you're comparing file system speed, I think,
you should measure the whole thing and be sure to create comparable
data.
The source files are
On 03/09/2012 01:43 AM, Adam Williamson wrote:
On Thu, 2012-03-08 at 22:19 -0700, Chris Murphy wrote:
I'm not sure how useful 'time' is as a benchmark for file copies.
Don't file transfers get cached and return to a console as 'complete'
long before the data is ever written, sometimes?
I'm
On 03/09/2012 08:42, Przemek Klosowski wrote:
On 03/09/2012 01:43 AM, Adam Williamson wrote:
On Thu, 2012-03-08 at 22:19 -0700, Chris Murphy wrote:
I'm not sure how useful 'time' is as a benchmark for file copies.
Don't file transfers get cached and return to a console as
'complete'
long
On Fri, Mar 9, 2012 at 10:11 AM, David Quigley seli...@davequigley.com wrote:
On 03/09/2012 08:42, Przemek Klosowski wrote:
On 03/09/2012 01:43 AM, Adam Williamson wrote:
On Thu, 2012-03-08 at 22:19 -0700, Chris Murphy wrote:
I'm not sure how useful 'time' is as a benchmark for file copies.
On 03/09/2012 11:00, Josef Bacik wrote:
On Fri, Mar 9, 2012 at 10:11 AM, David Quigley
seli...@davequigley.com wrote:
On 03/09/2012 08:42, Przemek Klosowski wrote:
On 03/09/2012 01:43 AM, Adam Williamson wrote:
On Thu, 2012-03-08 at 22:19 -0700, Chris Murphy wrote:
I'm not sure how useful
I'm not sure how useful 'time' is as a benchmark for file copies. But that's
what I used getting copy time for a folder containing 325 ~7.2MB files (DNGs)
totaling 2.3G. First I copied the files to tmpfs, and made all copies from that
to the destination. Destination device and partition is
On Thu, 2012-03-08 at 22:19 -0700, Chris Murphy wrote:
I'm not sure how useful 'time' is as a benchmark for file copies.
Don't file transfers get cached and return to a console as 'complete'
long before the data is ever written, sometimes?
I'm pretty sure you sometimes hit the case where you
On Mar 8, 2012, at 11:43 PM, Adam Williamson wrote:
On Thu, 2012-03-08 at 22:19 -0700, Chris Murphy wrote:
I'm not sure how useful 'time' is as a benchmark for file copies.
Don't file transfers get cached and return to a console as 'complete'
long before the data is ever written, sometimes?
On 09/03/12 07:43, Adam Williamson wrote:
Don't file transfers get cached and return to a console as 'complete'
long before the data is ever written, sometimes?
I've learned a long time ago, if you want to get near real numbers, you
have
to write data at least three times larger than memory
On Mar 9, 2012, at 12:10 AM, Matthias Runge wrote:
On 09/03/12 07:43, Adam Williamson wrote:
Don't file transfers get cached and return to a console as 'complete'
long before the data is ever written, sometimes?
I've learned a long time ago, if you want to get near real numbers, you
have
On 09/03/12 08:13, Chris Murphy wrote:
OK well if I'm going to use real files, and I don't want disk read
performance to be a factor in this, I kinda need to put the source
files into a ramdisk. So if it's 3x of cache, out of 7.4G free, a 6G
ramdisk would be at least 3x that of what remains
If your stuff depends on IO, you should give XFS a try :)
2012/3/2 Richard Shaw hobbes1...@gmail.com:
2012/3/2 Michał Piotrowski mkkp...@gmail.com:
More frightening benchmarks are shown here
http://www.youtube.com/watch?v=FegjLbCnoBw
That was a pretty cool video. Makes me want to try XFS
On Wed, Mar 7, 2012 at 10:27 PM, Nelson Marques nmo.marq...@gmail.com wrote:
If your stuff depends on IO, you should give XFS a try :)
Assuming you are not talking about a desktop system just buy a ssd and
never worry about I/O every again.
--
devel mailing list
devel@lists.fedoraproject.org
On Wed, Mar 7, 2012 at 10:30 PM, drago01 drag...@gmail.com wrote:
On Wed, Mar 7, 2012 at 10:27 PM, Nelson Marques nmo.marq...@gmail.com wrote:
If your stuff depends on IO, you should give XFS a try :)
Assuming you are not talking about a desktop system just buy a ssd and
never worry about I/O
On Mar 7, 2012, at 2:31 PM, drago01 wrote:
Assuming you are talking about a desktop system just buy a ssd and
never worry about I/O ever again.
Well, most of my colleagues and customers with desktop systems have rather
extreme storage requirements. Individual files multi gigabyte composited
Chris Murphy wrote:
Well, most of my colleagues and customers with desktop systems have rather
extreme storage requirements. Individual files multi gigabyte composited image
files. So an SSD is nice for speed, but cost prohibitive for everything to be
stored on SSD. What they need is a file
On Mar 7, 2012, at 3:01 PM, Michael Cronenworth wrote:
Yes, such a feature was submitted[1], but it has never been committed by
Chris AFAIK. There is also a OS-agnostic method of this. Seagate XT drives
use a small SSD as a cache. Then there is also a Windows method with Intel's
SSD Cache
On Wed, Mar 7, 2012 at 11:14 PM, Chris Murphy li...@colorremedies.com wrote:
On Mar 7, 2012, at 3:01 PM, Michael Cronenworth wrote:
Yes, such a feature was submitted[1], but it has never been committed by
Chris AFAIK. There is also a OS-agnostic method of this. Seagate XT drives
use a small
On Mar 7, 2012, at 3:31 PM, drago01 wrote:
On Wed, Mar 7, 2012 at 11:14 PM, Chris Murphy li...@colorremedies.com wrote:
On Mar 7, 2012, at 3:01 PM, Michael Cronenworth wrote:
Yes, such a feature was submitted[1], but it has never been committed by
Chris AFAIK. There is also a OS-agnostic
I think I'd rather see a portion of the SSD be a discrete device so that the
system and application scratch/swap can be pointed to it - rather than as
cache. I'm not sure that this data would always stay hot enough to be assured
of being in an SSD cache, whereas a discretely defined device
On Wed, Mar 7, 2012 at 11:53 PM, Chris Murphy li...@colorremedies.com wrote:
On Mar 7, 2012, at 3:31 PM, drago01 wrote:
On Wed, Mar 7, 2012 at 11:14 PM, Chris Murphy li...@colorremedies.com
wrote:
On Mar 7, 2012, at 3:01 PM, Michael Cronenworth wrote:
Yes, such a feature was
On Mar 7, 2012, at 3:58 PM, drago01 wrote:
It will come to a complete crawl which was exactly my point, faster
storage does not really help you in that situation.
Umm, that would seem to be fundamentally broken. I certainly haven't had this
experience on Mac OS X in cases where it has
Be careful what you wish for. btrfs is not a clear win on performance.
http://www.phoronix.com/scan.php?page=articleitem=linux_33_btrfsnum=1
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Hi,
2012/3/2 Neal Becker ndbeck...@gmail.com:
Be careful what you wish for. btrfs is not a clear win on performance.
More frightening benchmarks are shown here
http://www.youtube.com/watch?v=FegjLbCnoBw
This does not surprise me. Btrfs has more features than Ext4, so it
may be slower.
If
On Fri, Mar 02, 2012 at 11:33:28AM -0500, Neal Becker wrote:
Be careful what you wish for. btrfs is not a clear win on performance.
[...] phoronix.com [...]
Be careful what you believe.
Rich.
--
Richard Jones, Virtualization Group, Red Hat http://people.redhat.com/~rjones
New in Fedora
26 matches
Mail list logo
