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 03/09/2012 11:00, Josef Bacik wrote:
On Fri, Mar 9, 2012 at 10:11 AM, David Quigley
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 benchmar
On Fri, Mar 9, 2012 at 10:11 AM, David Quigley 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 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 be
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 pr
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
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
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
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 si
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, somet
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 co
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 alway
On Wed, Mar 07, 2012 at 04:01:48PM -0600, Michael Cronenworth wrote:
> 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 cos
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 star
On Wed, Mar 7, 2012 at 11:53 PM, Chris Murphy wrote:
>
>
> On Mar 7, 2012, at 3:31 PM, drago01 wrote:
>
>> On Wed, Mar 7, 2012 at 11:14 PM, Chris Murphy
>> wrote:
>>>
>>> On Mar 7, 2012, at 3:01 PM, Michael Cronenworth wrote:
Yes, such a feature was submitted[1], but it has never been commi
> 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 devi
On Mar 7, 2012, at 3:31 PM, drago01 wrote:
> On Wed, Mar 7, 2012 at 11:14 PM, Chris Murphy 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 th
On Wed, Mar 7, 2012 at 11:14 PM, Chris Murphy 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 SSD as a cache.
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 Cac
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 sy
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 composite
On Wed, Mar 7, 2012 at 10:30 PM, drago01 wrote:
> On Wed, Mar 7, 2012 at 10:27 PM, Nelson Marques 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.
Err.. that should
On Wed, Mar 7, 2012 at 10:27 PM, Nelson Marques 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
https://admin.fedorapro
If your stuff depends on IO, you should give XFS a try :)
2012/3/2 Richard Shaw :
> 2012/3/2 Michał Piotrowski :
>> 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 again.
>
> Richard
> --
> devel ma
2012/3/2 Michał Piotrowski :
> 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 again.
Richard
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
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 1
Hi,
2012/3/2 Neal Becker :
> 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 anyone wants Btrfs as
27 matches
Mail list logo
