-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On 08/05/13 16:13, Zhi Yong Wu wrote:
i want to know if btrfs hot relocation support is still meanful
It is to me. The problem with bcache is that it is a cache. ie if you
have a 256GB SSD and a 500GB HDD then you'll have total storage of 500GB.
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On 30/06/13 10:53, Garry T. Williams wrote:
~/.cache/chromium/Default/Cache ~/.cache/chromium/Default/Media\ Cache
I've taken to making ~/.cache be tmpfs and all the apps have been fine
with that. It also meant I didn't have to worry about my btrfs
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On 17/07/13 14:24, Florian Lindner wrote:
metadata ist mirrored on each device, data chunks are scattered more or
less randomly on one disk.
a) If one disk fails, is there any chance of data recovery? b) If not,
is there any advantage over a
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On 18/07/13 13:05, Chris Murphy wrote:
Sounds like if I have a degraded 'single' volume, I can simply cp or
rsync everything from that volume to another, and I'll end up with a
successful copy of the surviving data. True?
Not quite. I did it with
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On 22/08/13 07:07, Josef Bacik wrote:
Not sure what strict allocate = yes does,
I've worked on SMB servers before and can answer that. Historically the
way Windows apps (right back into the 16 bit days) have made sure there is
space for a file
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On 11/30/2014 05:58 PM, Qu Wenruo wrote:
2. Heavy dependency If use it, btrfs-progs will include RDBMS as
the make and runtime dependency. Such low level progs depend on
high level programs like sqlite3 may be very strange.
BTW SQLite is designed
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
I've been unable to find anything definitive about what happens if I use
RAID0 to join an SSD and HDD together with respect to performance
(latency, throughput). The future is obvious (hot data tracking, using
most appropriate device for the data,
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On 30/01/13 02:02, Hugo Mills wrote:
On Wed, Jan 30, 2013 at 01:27:37AM -0800, Roger Binns wrote:
In my specific case I have a 250GB SSD and a 500GB HDD, and about
250GB of files (constantly growing). One message I saw said that new
blocks
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On 30/01/13 04:01, Sander wrote:
Do you know about bcache and EnhanceIO ?
Yes, but there are two reasons I don't use them. One is that the capacity
of your cache is not included in the filesystem - ie with a 250GB SSD and
500GB the filesystem
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On 30/01/13 11:10, Filipe Brandenburger wrote:
You could try something like -l=linear on md-raid or something
similar on LVM to build a 750GB volume
That would also require wiping the filesystems and starting again(*). One
of the joys of btrfs
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On 09/03/13 12:31, Hugo Mills wrote:
Some time ago, and occasionally since, we've discussed altering the
RAID-n terminology to change it to an nCmSpP format, where n is
the number of copies, m is the number of (data) devices in a stripe per
copy,
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On 09/03/13 17:44, Hugo Mills wrote:
You've got at least three independent parameters to the system in order
to make that choice, though, and it's a fairly fuzzy decision problem.
You've got:
- Device redundancy - Storage overhead - Performance
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On 10/03/13 15:04, Hugo Mills wrote:
On Sat, Mar 09, 2013 at 09:41:50PM -0800, Roger Binns wrote:
The only constraints that matter are surviving N device failures, and
data not lost if at least N devices are still present. Under the
hood the best
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On 23/03/13 10:48, Eric Sandeen wrote:
Btrfs is a new copy on write filesystem for Linux aimed at
How much longer does new get to be there as the filesystem has been
going for well over half a decade.
+ autodefrag + Detect small random
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On 23/03/13 15:40, Eric Sandeen wrote:
I imagine it depends on the details of the workload storage as well.
If the people who write btrfs can't come up with some measures to deem
appropriateness, then how can the administrators who have even less
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On 26/03/13 21:27, Brendan Hide wrote:
On 11/03/13 02:21, Roger Binns wrote:
Why does all data have to be rewritten? Why does every piece of data
have to have exactly the same storage parameters in terms of
non-redundancy/performance/striping
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Is there any particular reason why I can't use DUP for data?
When I try to set it with balance there is a kernel message:
btrfs: dup for data is not allowed
The glossary at https://btrfs.wiki.kernel.org/index.php/Glossary says:
Regular data
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On 20/04/13 13:48, Hugo Mills wrote: On Sat, Apr 20, 2013 at 01:17:06PM
- -0700, Roger Binns wrote:
Is there any particular reason why I can't use DUP for data?
Technically, no. Performance is likely to suck if you use rotational
disks, and you
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On 20/04/13 14:23, Hugo Mills wrote:
You should upgrade anyway -- there's been a number of serious bugs in
btrfs fixed since then.
13.04 is imminent so I'll pick up a newer kernel as part of that anyway.
(Also Tanglu which I hope to move to intends
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On 20/04/13 23:32, Eric Sandeen wrote:
+#define btrfs_leak_list_add(new, head) do {} while (0); +#define
btrfs_leak_list_del(entry)do {} while (0);
Shouldn't the trailing semi-colons be omitted?
Roger
-BEGIN PGP SIGNATURE-
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On 27/04/13 19:53, Alex Elsayed wrote:
When using btrfs, run a recent kernel :P.
Every software developer says that of what they produce. Newer is almost
always better in many different axes.
Honestly, even leaving aside the lack of backporting,
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On 28/04/13 12:57, Harald Glatt wrote:
If you want better answers ...
There is a lot of good information at the wiki and it does see regular
updates. For example the performance mount options are on this page:
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
This occurs sporadically and the machine is somewhat useless as a result
since most filesystem operations then hang. For example even reboot
fails because it does filesystem operations.
kernel is regular kernel.org 3.12.6 compiled with Ubuntu's
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On 03/01/14 09:25, Marc MERLIN wrote:
Is there even a reason for this not to become a default mount option
in newer kernels?
autodefrag can go insane because it is unbounded. For example I have a
4GB RAM system (3.12, no gui) that kept hanging. I
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On 18/01/14 17:13, Marc MERLIN wrote:
For what it's worth I also tried a btrfs convert on ubuntu precise
with their stock kernel and old btrfs-tools and it mostly destroyed
the filesystem too,
Just in case some folks think btrfs-convert never
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On 16/01/14 11:23, Toggenburger Lukas wrote:
One of my ideas was to work on Btrfs.
One thing I would like see it automatic backup copies of data. For
example if you are only using 10% of the total space then make an
additional 9 copies of the data
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On 22/01/14 04:12, David Sterba wrote:
I have done some work here, so far it's stalled due to more important
work.
https://btrfs.wiki.kernel.org/index.php/Project_ideas#Compression_enhancements
Do you have other suggestions beyond what's
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On 23/01/14 10:36, David Sterba wrote:
'Theoretical best' seems too vaguely defined,
It seems like a good thing for someone to tackle as part of a master's
thesis :-)
with compression it's always some trade-off and compromise
Which you can put in
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On 03/02/14 09:27, Josef Bacik wrote:
It is so totally broken that I don't want it being turned on by anybody
who can't edit this and change it themselves.
The symptoms I saw are huge amounts of kernel memory consumption, possibly
till exhaustion
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On 10/02/14 10:24, cwillu wrote:
The regular df data used number should be the amount of space required
to hold a backup of that content (assuming that the backup maintains
reflinks and compression and so forth).
There's no good answer for
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On 10/02/14 19:13, cwillu wrote:
But the answer changes dramatically depending on whether it's large
numbers of small files or a small number of large files, and the
conservative worst-case choice means we report a number that is half
what is
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
I can't start a scrub because it is running, and can't cancel it
because it isn't running! How do I get out of this state? OS is
Ubuntu 14.10.
$ uname -r
3.16.0-28-generic
# btrfs scrub start .
ERROR: scrub is already running.
To cancel use 'btrfs
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On 01/08/2015 08:53 AM, Lennart Poettering wrote:
this will help little if we change things in the beginning of the
file,
Have you considered changing the format so that those pointers are
stored at the end of the file, letting data always be
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On 06/04/2015 04:25 PM, Anand Jain wrote:
typically ready cli is to check disk pool status in an unmounted
state.
On my desktop with btrfs RAID0 on two partitions, the exit code of
ready is always 1. On my laptop with btrfs RAID0 on two
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
This is on current Ubuntu 15.04. What is device ready unhappy with?
Note that the root filesystem and /home (both subvolumes of this) are
mounted and working perfectly, and even where the commands are run from.
$ sudo btrfs fi show /dev/sda1
Label:
35 matches
Mail list logo
