Le dimanche 9 mars 2014 08:48:20 KC a écrit :
I am experiencing massive performance degradation on my BTRFS root
partition on SSD.
BTW, is BTRFS still a SSD-killer ? It had this reputation a while ago, and I'm
not sure if this still is the case, but I don't dare (yet) converting to BTRFS
one
Le dimanche 9 mars 2014 11:01:17 vous avez écrit :
This ThinkPad T520 has been with BTRFS since installation of the Debian
sid system on it with Kernel 2.6.39 or even 2.6.38 (where Sandybridge
graphics didn´t work so well as today yet).
So that much to any FUD about BTRFS and SSDs.
Wow !
On Sun, Mar 09, 2014 at 11:23:29AM +0100, Swâmi Petaramesh wrote:
Le dimanche 9 mars 2014 11:01:17 vous avez écrit :
This ThinkPad T520 has been with BTRFS since installation of the Debian
sid system on it with Kernel 2.6.39 or even 2.6.38 (where Sandybridge
graphics didn´t work so well as
Am Sonntag, 9. März 2014, 11:33:50 schrieb Hugo Mills:
On Sun, Mar 09, 2014 at 11:23:29AM +0100, Swâmi Petaramesh wrote:
Le dimanche 9 mars 2014 11:01:17 vous avez écrit :
This ThinkPad T520 has been with BTRFS since installation of the Debian
sid system on it with Kernel 2.6.39 or even
Le dimanche 9 mars 2014 11:33:50 Hugo Mills a écrit :
ssd should be activated automatically on any non-rotational device.
ssd_spread is generally slower on modern SSDs than the ssd option.
discard is, except on the very latest hardware, a synchronous command
(it's a limitation of the SATA
Hi!
Since a few days this ThinkPad T520 has 780 GB SSD capacity. The 300 GB of
the Intel SSD 320 were almost full and that 480 GB Crucial m500 mSATA SSD
was cheap enough to just buy it.
I created a new logical volume for big and not that often changed files that
is just on the msata and moved
Hi!
On 3.14.0-rc4-tp520 (compiled with gcc 4.8.2) shrinking my /home from about
260 GiB to 150 GiB resulted in a BTRFS hang.
First it relocated block groups, but then on one the btrfs command was
blocked for more than 120 seconds.
A second attempt after a reboot quickly had the same result.
I
Travis Cross posted on Sat, 08 Mar 2014 20:35:16 + as excerpted:
The filesystem here was likely created with Linux 3.2 and hasn't seen
much use for awhile, until today I mounted it to try to btrfs send off
those volumes.
xaba noted this could be the result of some 3.2-era kernel bug.
Chris Samuel posted on Sun, 09 Mar 2014 15:13:42 +1100 as excerpted:
On Fri, 7 Mar 2014 04:14:16 PM Sander wrote:
But if the filesystem or underlaying disk goes up in flames, the
snapshots are toast as well. So you need additional backups, preferably
not on the same hardware, for real
Wolfgang Mader posted on Fri, 07 Mar 2014 11:13:51 +0100 as excerpted:
Duncan, thank you for this comprehensive post. Really helpful as always!
[...]
As for restoring, since a snapshot is a copy of the filesystem as it
existed at that point, and the method btrfs exposes for accessing them
Eric Mesa posted on Fri, 07 Mar 2014 14:03:44 + as excerpted:
Duncan - thanks for this comprehensive explanation. For a huge portion
of your reply...I was all wondering why you and others were saying
snapshots aren't backups. They certainly SEEMED like backups. But now I
see that the
Swâmi Petaramesh swami at petaramesh.org writes:
Actually deduplication WAS the reason why I recently made the move to BTRFS
again, for deduplication in ZFS is working, but *SO* memory hungry and
performance killer unless you have *lots* of RAM...
If you think about what dedup is has to
On 03/09/2014 04:17 AM, Swâmi Petaramesh wrote:
Le dimanche 9 mars 2014 08:48:20 KC a écrit :
I am experiencing massive performance degradation on my BTRFS
root partition on SSD.
BTW, is BTRFS still a SSD-killer ? It had this reputation a while
ago, and I'm not sure if this still is the
2014-03-09 18:36 GMT+01:00 Austin S Hemmelgarn ahferro...@gmail.com:
On 03/09/2014 04:17 AM, Swâmi Petaramesh wrote:
Le dimanche 9 mars 2014 08:48:20 KC a écrit :
I am experiencing massive performance degradation on my BTRFS
root partition on SSD.
BTW, is BTRFS still a SSD-killer ? It had
S... was this a help to anyone?
On 03/06/14 11:48, Mark Murawski wrote:
Not the same problem, but I do have a lockup with another situation.
I tried adding some new devices... but accidentally screwed up the
syntax (not sure if this had anything to do with the lockup)
btrfs device add /
On Fri, 7 Mar 2014 19:00:08 -0500, Josef Bacik wrote:
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On 02/20/2014 05:08 AM, Miao Xie wrote:
Signed-off-by: Miao Xie mi...@cn.fujitsu.com --- fs/btrfs/ctree.c
| 25 ++--- fs/btrfs/ctree.h | 39
Any comments on this set of patches ?
Thanks, Anand
On 07/03/2014 23:48, Anand Jain wrote:
The intended usage of total_devices and num_devices
should be recorded in the comments so that these
two counters can be used correctly as originally
intended.
As of now there appears to be slight
On Sat, 8 Mar 2014 08:35:17 +0100, Swâmi Petaramesh wrote:
Hi there,
I tried to perform an incremental backup as described in
https://btrfs.wiki.kernel.org/index.php/Incremental_Backup between 2 external
USB drives,
The 1st btrfs send foo/snap1 | btrfs receive bar went well, although it
So this is a stress test for btrfs quota operations. it can also
detect the following commit fixed problem:
4082bd3d73(Btrfs: fix oops when writting dirty qgroups to disk)
Signed-off-by: Wang Shilong wangsl.f...@cn.fujitsu.com
---
v1-v2:
switch into new helper _run_btrfs_util_prog()
---
Test flow is to run fsstress after triggering quota rescan.
the ruler is simple, we just remove all files and directories,
sync filesystem and see if qgroup's ref and excl are nodesize.
Signed-off-by: Wang Shilong wangsl.f...@cn.fujitsu.com
---
v1-v2:
switch into new helper
Add missing test for btrfs quota groups feature,test idea is to create
a parent qgroup that groups some subvolume groups, we try to write
some data into every subvolume and then check if we exceed parent
qgroup's limit size.
Signed-off-by: Wang Shilong wangsl.f...@cn.fujitsu.com
---
v1-v2:
21 matches
Mail list logo
