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
[...]
This could be
On Sun, 9 Dec 2012 06:17:39 +0100 (CET)
Jan Engelhardt jeng...@inai.de 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
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 to
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 over
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
new blocks
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
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 slowness could be
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
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.e.
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 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
On Mon, Oct 8, 2012 at 8:08 AM, Swâmi Petaramesh sw...@petaramesh.org 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
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
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
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
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,
I
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 you check
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
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
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 disk
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 disk
Swâmi Petaramesh swami at 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
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 disk
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
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 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:
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 you
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 the
28 matches
Mail list logo
