[Top] [All Lists]

Re: Delaylog information enquiry

To: Dave Chinner <david@xxxxxxxxxxxxx>
Subject: Re: Delaylog information enquiry
From: Grozdan <neutrino8@xxxxxxxxx>
Date: Wed, 30 Jul 2014 23:18:11 +0200
Cc: Brian Foster <bfoster@xxxxxxxxxx>, "Frank ." <frank_1005@xxxxxxx>, "xfs@xxxxxxxxxxx" <xfs@xxxxxxxxxxx>
Delivered-to: xfs@xxxxxxxxxxx
Dkim-signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=NY28fxL/jv/m9B97092FnK0Fjj1D7l2K99/BRAbKwlc=; b=q58pLrhmrBthMMGrGg3c0kdPD6tv0m4aPMTxw5jJ9bRNzs0k2dN5Y0W+nW5+J8NZJi VjwhPYEh3PYAFhCbMX8K3/vSPPjQOuLThbs10K1fEIXNtnYs61vD9k8JVodWtycW7is8 uDskJDhZnbX52pRpPixHsJc+w1uKsf7b++XfCXkH4Ko6DUbiFuuA722eOzNz/zFYaFTQ TTnfN+WH0brSAKsOAFw8w0WQY40NMqanOoyEitx1NYEDNyawJA8QfiFSFvEOw6EpuRGO BGYrDdPcdcZxnL1W1rHz8iE+0nkCWUXuhIS5JpqaCGxA0sQwbyO2ZKn3ILYLXFvVf73w XyJA==
In-reply-to: <20140730081858.GN26465@dastard>
References: <DUB129-W7B2973281D7E749989D43EEF80@xxxxxxx> <20140729123815.GA13120@xxxxxxxxxxxxxxx> <20140729234151.GJ26465@dastard> <CAFLt3phu1kJUjFyP8-+zkRPEsiv8ue=c+W+Ym8PYS1zd3kHyzw@xxxxxxxxxxxxxx> <20140730081858.GN26465@dastard>
On Wed, Jul 30, 2014 at 10:18 AM, Dave Chinner <david@xxxxxxxxxxxxx> wrote:
> On Wed, Jul 30, 2014 at 07:42:32AM +0200, Grozdan wrote:
>> On Wed, Jul 30, 2014 at 1:41 AM, Dave Chinner <david@xxxxxxxxxxxxx> wrote:
>> > Note that this does not change file data behaviour. In this case you
>> > need to add the "sync" mount option, which forces all buffered IO to
>> > be synchronous and so will be *very slow*. But if you've already
>> > turned off the BBWC on the RAID controller then your storage is
>> > already terribly slow and so you probably won't care about making
>> > performance even worse...
>> Dave, excuse my ignorant questions
>> I know the Linux kernel keeps data in cache up to 30 seconds before a
>> kernel daemon flushes it to disk, unless
>> the configured dirty ratio (which is 40% of RAM, iirc) is reached
> 10% of RAM, actually.
>> before these 30 seconds so the flush is done before it
>> What I did is lower these 30 seconds to 5 seconds so every 5 seconds
>> data is flushed to disk (I've set the dirty_expire_centisecs to 500).
>> So, are there any drawbacks in doing this?
> Depends on your workload. For a desktop, you probably won't notice
> anything different. For a machine that creates lots of temporary
> files and then removes them (e.g. build machines) then it could
> crater performance completely because it causes writeback before the
> files are removed...
>> I mean, I don't care *that*
>> much for performance but I do want my dirty data to be on
>> storage in a reasonable amount of time. I looked at the various sync
>> mount options but they all are synchronous so it is my
>> impression they'll be slower than giving the kernel 5 seconds to keep
>> data and then flush it.
>> From XFS perspective, I'd like to know if this is not recommended or
>> if it is? I know that with setting the above to 500 centisecs
>> means that there will be more writes to disk and potentially may
>> result in tear & wear, thus shortening the lifetime of the
>> storage
>> This is a regular desktop system with a single Seagate Constellation
>> SATA disk so no RAID, LVM, thin provision or anything else
>> What do you think? :)
> I don't think it really matters either way. I don't change
> the writeback time on my workstations, build machines or test
> machines, but I actually *increase* it on my laptops to save power
> by not writing to disk as often. So if you want a little more
> safety, then reducing the writeback timeout shouldn't have any
> significant affect on performance or wear unless you are doing
> something unusual....
> Cheers,
> Dave.

Thanks Dave :)

I don't want to start another thread as this is my last question but
it's one unrelated to the original question from Frank

One of my partitions was almost full (there was 5 GB over according to
df -h). I had about 8 torrents open in the client, all sizes between 4
and 6 GB (they were all downloaded and got never "released" from the
client as I was seeding back). When I tried to add a torrent to
download which was 3 GB, the client reported that there was no more
space left over on the partition. I suspect this is related to
speculative preallocation and because the 8 torrents were all "open"
they still had extra space allocated by the speculative preallocation
and thus I couldn't add the 3GB torrent even though df says there was
5GB over but in reality it was much less. Am I correct on this or is
there something completely else that happened?

Thanks ;)

> --
> Dave Chinner
> david@xxxxxxxxxxxxx

Yours truly

<Prev in Thread] Current Thread [Next in Thread>