This comes from one of btrfs's project ideas,
As we defragment files, we break any sharing from other snapshots.
The balancing code will preserve the sharing, and defrag needs to grow this
as well.
Now we're able to fill the blank with this patch, in which we make full use of
backref walking
This feature works on our crucial write endio path, so if we've got
lots of fragments to process, it will be kind of a disaster to the
performance, so I make such a change.
One can benifit from it while mounting with '-o snap_aware_defrag'.
Signed-off-by: Liu Bo bo.li@oracle.com
---
Remove an invalid size check up from btrfs_shrink_dev().
The new size should not larger than the device-total_bytes as it was
already verified before coming to here(i.e. new_size old_size).
Remove invalid check up for btrfs_shrink_dev().
Signed-off-by: Jie Liu jeff@oracle.com
---
On Oct 25, 2012, at 9:36 PM, cwillu cwi...@cwillu.com wrote:
On Thu, Oct 25, 2012 at 8:33 PM, Chris Murphy li...@colorremedies.com wrote:
So what's the intended distinction between 'fi df' and 'fi show'? Because
for months using btrfs I'd constantly be confused which command was going to
On Oct 26, 2012, at 7:58 PM, cwillu cwi...@cwillu.com wrote:
I'd argue that everything should be absolute references to subvolumes
(/@home, /@, etc), and neither set-default nor subvolume id's should
be touched.
grub's core.img prefix is relative to the current default subvolume. I'm
Am Donnerstag, 25. Oktober 2012 schrieb Goffredo Baroncelli:
Hi all,
this is a new attempt to improve the output of the command btrfs fi
df.
The previous attempt received a good reception. However there was no a
general consensus about the wording.
Moreover I still didn't understand
On Oct 26, 2012, at 9:03 PM, Fajar A. Nugraha l...@fajar.net wrote:
So back to the original question, I'd suggest NOT to use either
send/receive or set-default. Instead, setup multiple boot environment
(e.g. old version, current version) and let user choose which one to
boot using a menu.
3.6.3-3.fc18.x86_64.debug
btrfs-progs-0.20.rc1.20121017git91d9eec-1.fc18.x86_64
I'm getting a very different result with this kernel compared to 3.6.2, when I
do the same thing. I fill the btrfs volume to 97% full again, no errors. Add a
device of the *same* size, and then device delete.
In
On 27 Oct 2012 18:43 +0200, from mar...@lichtvoll.de (Martin Steigerwald):
Possibly this could be done tabular as well, like:
vdb vdc vdd
Data, RAID 0 307,25MB307,25MB307,25MB
…
System,RAID1 - 8MB 8MB
On Sat, Oct 27, 2012 at 09:56:45PM +, Michael Kjörling wrote:
I came across the tidbit that ZFS has a contract guarantee that the
data read back will either be correct (the checksum computed over the
data read from the disk matches the checksum stored on disk), or you
get an I/O error.
On 27 Oct 2012 23:02 +0100, from h...@carfax.org.uk (Hugo Mills):
I came across the tidbit that ZFS has a contract guarantee that the
data read back will either be correct (the checksum computed over the
data read from the disk matches the checksum stored on disk), or you
get an I/O error.
Am Samstag, 27. Oktober 2012 schrieb Michael Kjörling:
On 27 Oct 2012 18:43 +0200, from mar...@lichtvoll.de (Martin
Steigerwald):
Possibly this could be done tabular as well, like:
vdb vdc vdd
Data, RAID 0 307,25MB307,25MB
On Sun, Oct 28, 2012 at 12:30:44AM +0200, Martin Steigerwald wrote:
Am Samstag, 27. Oktober 2012 schrieb Michael Kjörling:
On 27 Oct 2012 18:43 +0200, from mar...@lichtvoll.de (Martin
Steigerwald):
Possibly this could be done tabular as well, like:
vdb
On 27 Oct 2012 23:38 +0100, from h...@carfax.org.uk (Hugo Mills):
Data: RAID 0 System: RAID 1 Unused
/dev/vdb 307.25 MB-2.23 GB
/dev/vdc 307.25 MB 8 MB2.69 GB
/dev/vdd 307.25 MB 8 MB2.24 GB
On Oct 27, 2012, at 1:55 PM, Michael Kjörling mich...@kjorling.se wrote:
Data: RAID 0 System: RAID 1 Unused
/dev/vdb 307.25 MB-2.23 GB
/dev/vdc 307.25 MB 8 MB2.69 GB
/dev/vdd 307.25 MB 8 MB2.24 GB
15 matches
Mail list logo
