On 12/09/12 12:38, Hugo Mills wrote:
On Sun, Dec 09, 2012 at 12:20:46PM +0100, Swâmi Petaramesh wrote:
Le 09/12/2012 11:41, Roman Mamedov a écrit :
CoW filesystem incurs fragmentation by its nature, not specifically snapshots.
Even without snapshots, rewriting portions of existing files will wr
On Sunday 2012-12-09 11:41, Roman Mamedov wrote:
>>
>> Absolutely. COW snapshots cause severe fragmentation (it's
>> in their nature).
>
>CoW filesystem incurs fragmentation by its nature, not specifically snapshots.
>Even without snapshots, rewriting portions of existing files will write the
>ne
On Sun, Dec 09, 2012 at 12:20:46PM +0100, Swâmi Petaramesh wrote:
> Le 09/12/2012 11:41, Roman Mamedov a écrit :
> > CoW filesystem incurs fragmentation by its nature, not specifically
> > snapshots.
> > Even without snapshots, rewriting portions of existing files will write the
> > new blocks not
Le 09/12/2012 11:41, Roman Mamedov a écrit :
> CoW filesystem incurs fragmentation by its nature, not specifically snapshots.
> Even without snapshots, rewriting portions of existing files will write the
> new blocks not over the original ones, but elsewhere, thus increasing
> fragmentation.
Is it
On Sun, 9 Dec 2012 06:17:39 +0100 (CET)
Jan Engelhardt wrote:
>
> On Sunday 2012-10-07 16:48, Martin Steigerwald wrote:
> >>
> >> # btrfs su li /
> >> ID 256 top level 5 path UBUNTU
> >> ID 259 top level 5 path UBUNTU/@
> >> ID 261 top level 5 path UBUNTU/@tmp
> >> ID 262 top level 5 path UBUNT
Am Sonntag, 9. Dezember 2012 schrieb Jan Engelhardt:
> On Sunday 2012-10-07 16:48, Martin Steigerwald wrote:
> >>
> >> # btrfs su li /
> >> ID 256 top level 5 path UBUNTU
> >> ID 259 top level 5 path UBUNTU/@
> >> ID 261 top level 5 path UBUNTU/@tmp
> >> ID 262 top level 5 path UBUNTU/@home
> >>[.
On Sunday 2012-10-07 16:48, Martin Steigerwald wrote:
>>
>> # btrfs su li /
>> ID 256 top level 5 path UBUNTU
>> ID 259 top level 5 path UBUNTU/@
>> ID 261 top level 5 path UBUNTU/@tmp
>> ID 262 top level 5 path UBUNTU/@home
>>[...]
>
>This could be 100 or more subvolumes / snapshots.
>Maybe slow
On 2012-10-07 15:19, Swâmi Petaramesh wrote:
> Hi again ;-)
> Le 07/10/2012 14:33, Alex a écrit :
>> 1. Convert to a 16k or 32k leafsize.
> How should I do this ? Can I do this on a live FS, and isn't this going
> to double my on-disk used space (I have active snapshots...)
>> 2. defragment (each n
On 10/08/2012 05:50 PM, Swâmi Petaramesh wrote:
Hi again Goffredo,
Le 08/10/2012 13:38, Goffredo Baroncelli a écrit :
I fear that both the combination of autodefrag and the high number of
snapshot could be the root-cause of the the bad performance.
I've removed, on one of my machines, all snap
On Mon, Oct 08, 2012 at 10:15:51AM -0600, Swâmi Petaramesh wrote:
> Le 08/10/2012 18:09, Josef Bacik a écrit :
> > Can you get sysrq+w when you are seeing slowness? Usually bootup slow times
> > means you don't have space_cache enabled or your cache is being evicted for
> > some
> > reason, can y
Le 08/10/2012 18:09, Josef Bacik a écrit :
> Can you get sysrq+w when you are seeing slowness? Usually bootup slow times
> means you don't have space_cache enabled or your cache is being evicted for
> some
> reason, can you check dmesg after bootup for messages related to space cache?
> Thanks,
On Sun, Oct 07, 2012 at 03:26:32AM -0600, Swâmi Petaramesh wrote:
> Hi,
>
> I have 4 machines, all converted to BTRFS about 6 months ago, now all
> running Ubuntu Quantal with kernel 3.5.0-17
>
> The matter is that all these machines are now getting slower and slower
> everyday, every disk access
Hi again Goffredo,
Le 08/10/2012 13:38, Goffredo Baroncelli a écrit :
> I fear that both the combination of autodefrag and the high number of
> snapshot could be the root-cause of the the bad performance.
I've removed, on one of my machines, all snapshots but three per subvol
(keeping the oldests
Le 08/10/2012 13:38, Goffredo Baroncelli a écrit :
> The autodefrag option is per filesystem not per subvolume. The settings
> of the first subvolueme is used also for the other ones.
Uh !
So there is no interest in creating several subvols, some for which
files should be autodefragged, and some n
On Mon, Oct 8, 2012 at 8:08 AM, Swâmi Petaramesh wrote:
> Le 08/10/2012 00:47, Goffredo Baroncelli a écrit :
>> Please could you clarify if you are using the "autodefrag" options
>> when you have the performance problem ?
>
> I use autodefrag on all volumes systematically, except on volumes that I
Le 07/10/2012 16:44, Martin Steigerwald a écrit :
> I think you need to backup, reformat and restore from backup for now.
No way. 4 machines on each of which 2 to 4 different OSes are sharing
the same BTRFS volume !
If I ever need to reformat/reinstall all this, the new format won't be
BTRFS ! I
Hi Martin,
Le 07/10/2012 16:48, Martin Steigerwald a écrit :
> Where is this volume pool located on? On which drive(s)?
All the concerned machines are laptops with a single physical HD...
> This could be 100 or more subvolumes / snapshots.
>
> Maybe slowness could be related to this one.
That's a
Le 08/10/2012 00:47, Goffredo Baroncelli a écrit :
> Please could you clarify if you are using the "autodefrag" options
> when you have the performance problem ?
I use autodefrag on all volumes systematically, except on volumes that I
use for really big files that would always be defragmenting (i.
On 10/07/2012 04:44 PM, Martin Steigerwald wrote:
Plus, with respect to snapshots, isn't this going to increase a lot my
> used disk space ?
I don´t think so, but I will leave this to a developer to answer.
IIRC the defrag is not [fully] snapshot aware, so de-frag-ging a
snapshot-ted file sho
Am Sonntag, 7. Oktober 2012 schrieb Swâmi Petaramesh:
> Le 07/10/2012 12:59, Martin Steigerwald a écrit :
> > btrfs fi df (preferably with btrfs tools from Goffredo)
> > btrfs fi show
>
> I don't think I miss any free space ;-)
Well I could I know this beforehand?
> (From one of my machines, but
Am Sonntag, 7. Oktober 2012 schrieb Swâmi Petaramesh:
> Hi again ;-)
>
> Le 07/10/2012 14:33, Alex a écrit :
> > 1. Convert to a 16k or 32k leafsize.
>
> How should I do this ? Can I do this on a live FS, and isn't this going
> to double my on-disk used space (I have active snapshots...)
I think
Am Sonntag, 7. Oktober 2012 schrieb Swâmi Petaramesh:
> Le 07/10/2012 15:00, Martin Steigerwald a écrit :
> > I forgot to mention mount options? Which one do you use?
>
> root@tethys:/etc# grep btrfs fstab
> /dev/VG1/BTR_POOL/btrfs
> subvol=UBUNTU/@,space_cache,autodefrag,compress=lzo,r
Le 07/10/2012 12:59, Martin Steigerwald a écrit :
> btrfs fi df (preferably with btrfs tools from Goffredo)
> btrfs fi show
I don't think I miss any free space ;-)
(From one of my machines, but the others have rather the same
architecture...)
# btrfs fi sh
failed to read /dev/sr0
Label: 'BTR_POO
Hi again ;-)
Le 07/10/2012 14:33, Alex a écrit :
>
> 1. Convert to a 16k or 32k leafsize.
How should I do this ? Can I do this on a live FS, and isn't this going
to double my on-disk used space (I have active snapshots...)
> 2. defragment (each non-trivial file) every now and again
I believed that
Le 07/10/2012 15:00, Martin Steigerwald a écrit :
> I forgot to mention mount options? Which one do you use?
root@tethys:/etc# grep btrfs fstab
/dev/VG1/BTR_POOL/btrfs
subvol=UBUNTU/@,space_cache,autodefrag,compress=lzo,relatime0 0
/dev/sda2/bootbtrfs
subvol=UBUNTU
Am Sonntag, 7. Oktober 2012 schrieb Swâmi Petaramesh:
> Hi,
>
> I have 4 machines, all converted to BTRFS about 6 months ago, now all
> running Ubuntu Quantal with kernel 3.5.0-17
>
> The matter is that all these machines are now getting slower and slower
> everyday, every disk access causing the
Swâmi Petaramesh petaramesh.org> writes:
>
> Hi,
>
> I have 4 machines, all converted to BTRFS about 6 months ago, now all
> running Ubuntu Quantal with kernel 3.5.0-17
1. Convert to a 16k or 32k leafsize.
2. defragment (each non-trivial file) every now and again [eg. find / -size +16k
-type
Am Sonntag, 7. Oktober 2012 schrieb Swâmi Petaramesh:
> Hi,
>
> I have 4 machines, all converted to BTRFS about 6 months ago, now all
> running Ubuntu Quantal with kernel 3.5.0-17
>
> The matter is that all these machines are now getting slower and slower
> everyday, every disk access causing the
Am Sonntag, 7. Oktober 2012 schrieb Swâmi Petaramesh:
> Hi,
>
> I have 4 machines, all converted to BTRFS about 6 months ago, now all
> running Ubuntu Quantal with kernel 3.5.0-17
>
> The matter is that all these machines are now getting slower and slower
> everyday, every disk access causing the
Hi,
I have 4 machines, all converted to BTRFS about 6 months ago, now all
running Ubuntu Quantal with kernel 3.5.0-17
The matter is that all these machines are now getting slower and slower
everyday, every disk access causing the disk to be 100% busy for long
periods, to the point that I'm now se
30 matches
Mail list logo
