with lzo, and presumably lz4 the 128k extents of packed data are livable.
on bootable thumbdrive images esp. with merged metadata I think
favoring greater fragmentation vs. the current 128k would help, and
giving larger files momentum to occupy more than 128k extents would
also help.
On Wed, Mar 2
_require_nobigloopfs has been removed.
We should use _require_no_large_scratch_dev in the test script.
Signed-off-by: Wang Sheng-Hui
---
276 |3 +--
1 file changed, 1 insertion(+), 2 deletions(-)
diff --git a/276 b/276
index 40b30cf..87363ca 100755
--- a/276
+++ b/276
@@ -58,8 +58,7 @@ _ne
We should free leaf and root before returning from the error
handling code.
Signed-off-by: Tsutomu Itoh
---
fs/btrfs/disk-io.c | 12 +---
1 file changed, 9 insertions(+), 3 deletions(-)
diff --git a/fs/btrfs/disk-io.c b/fs/btrfs/disk-io.c
index 7d84651..b1b5baa 100644
--- a/fs/btrfs/dis
On Wed, Mar 20, 2013 at 01:27:11PM -0600, Roger Pack wrote:
> I see from
> https://btrfs.wiki.kernel.org/index.php/Compression#How_do_I_enable_compression.3F
> "LZ4" support is currently being added. Here's my +1 for also adding
> something with "high" compression like xz or lzma, since they
> ba
On Mar 20, 2013, at 1:24 PM, Roman Mamedov wrote:
> On Wed, 20 Mar 2013 12:19:18 -0600
> Chris Murphy wrote:
>
>>> 195 Hardware_ECC_Recovered 0x001a 057 055 000Old_age Always
>>>- 63508940
>
>> With such high ECC recovered events, I suspect SDC.
>
> If it's a Seag
received here.
+1
jffs2 has a lzma kernel compressor patch for 2.6 based on the lzma
reference (7z?) source and lzo kernel compressor
On Wed, Mar 20, 2013 at 12:27 PM, Roger Pack wrote:
>
> Looks like this message was initially viewed as spam because of an
> HTML subpart...trying it again...
>
Am Mittwoch, 20. März 2013 schrieb David Sterba:
> Hi,
>
> finally removing the obsolete utilities, adding the fragmentation
> visualisation tool in exchange, setting of io priority for scrub, few
> more fixes and updates to the build system.
The fragmentation visuation tool works nicely. Tried i
Looks like this message was initially viewed as spam because of an
HTML subpart...trying it again...
-- Forwarded message --
From: Roger Pack
Date: Wed, Mar 20, 2013 at 1:25 PM
Subject: +1 for xz
To: linux-btrfs@vger.kernel.org
I see from
https://btrfs.wiki.kernel.org/index.php
On Wed, 20 Mar 2013 12:19:18 -0600
Chris Murphy wrote:
> > 195 Hardware_ECC_Recovered 0x001a 057 055 000Old_age Always
> >- 63508940
> With such high ECC recovered events, I suspect SDC.
If it's a Seagate drive, this is absolutely normal.
All Seagate drives have a hi
Am Dienstag, 19. März 2013 schrieb Marek Otahal:
> Hi,
>
> just reading chattr manpage..
>
> On Monday 18 March 2013 14:15:17 you wrote:
> > Hi,
> >
> > After reading through the btrfs documentation I'm curious to know if
> > it's possible to ever securely erase a file from a btrfs filesystem (o
>> # rm -rf *
>> rm: cannot remove 'drivers/misc/lis3lv02d/lis3lv02d.c': Stale NFS file handle
>> rm: cannot remove 'drivers/misc/lis3lv02d/lis3lv02d.c': Stale NFS file handle
>> rm: cannot remove 'drivers/misc/lis3lv02d/lis3lv02d.c': Stale NFS file handle
>> rm: cannot remove 'drivers/misc/lis3lv0
Am Mittwoch, 20. März 2013 schrieb Frédéric COIFFIER:
> > But I really think BTRFS displays the filename affected meanwhile. So
> > maybe if it does not, its some metadata being affected? So output of btrfsck
> > hints at that and that you can´t remove the file does as well. What happens
> > if you
On Mar 20, 2013, at 7:33 AM, Frédéric COIFFIER
wrote:
>
> 195 Hardware_ECC_Recovered 0x001a 057 055 000Old_age Always
> - 63508940
> 197 Current_Pending_Sector 0x0012 100 100 000Old_age Always
> - 0
> 198 Offline_Uncorrectable 0x0010 100
Hi,
finally removing the obsolete utilities, adding the fragmentation visualisation
tool in exchange, setting of io priority for scrub, few more fixes and updates
to the build system.
git://repo.or.cz/btrfs-progs-unstable/devel.git integration-20130320
david
---
shortlog:
Anand Jain (1
On Mon, Mar 04, 2013 at 04:37:06PM -0600, Carey Underwood wrote:
> Device scanning waits on the uuid_mutex, which can result in a very long
> wait if dev delete is shrinking the device.
>
> + mutex_unlock(&uuid_mutex);
> ret = btrfs_shrink_device(device, 0);
> + mutex_lock(&uuid_mute
Signed-off-by: David Sterba
---
fs/btrfs/super.c |6 ++
1 files changed, 6 insertions(+), 0 deletions(-)
diff --git a/fs/btrfs/super.c b/fs/btrfs/super.c
index 5f21797..808648f 100644
--- a/fs/btrfs/super.c
+++ b/fs/btrfs/super.c
@@ -81,6 +81,12 @@ static const char *btrfs_decode_error(i
To resolve backrefs, ROOT_REPLACE operations in the tree mod log are
required to be tied to at least one KEY_REMOVE_WHILE_FREEING operation.
Therefore, those operations must be enclosed by tree_mod_log_write_lock()
and tree_mod_log_write_unlock() calls.
Those calls are private to the tree_mod_log_
To resolve backrefs, ROOT_REPLACE operations in the tree mod log are
required to be tied to at least one KEY_REMOVE_WHILE_FREEING operation.
Therefore, those operations must be enclosed by tree_mod_log_write_lock()
and tree_mod_log_write_unlock() calls.
Those calls are private to the tree_mod_log_
Hi Martin,
Thank you for your reply.
Le samedi 16 mars 2013 19:16:54 Martin Steigerwald a écrit :
> Am Freitag, 8. März 2013 schrieb Frédéric COIFFIER:
> > # btrfs scrub status /
> > scrub status for 6b6ea99b-edee-498d-bf07-f3a3f1cba2f3
> > scrub started at Thu Mar 7 20:12:31 2013 and fi
The messages
btrfs: unlinked 123 orphans
btrfs: truncated 456 orphans
are not useful to regular users and raise questions whether there are
problems with the filesystem.
Signed-off-by: David Sterba
---
fs/btrfs/inode.c |4 ++--
1 files changed, 2 insertions(+), 2 deletions(-)
diff --g
This mount option was a workaround when subvol= assumed path relative
to the default subvolume, not the toplevel one. This was fixed long time
ago and subvolrootid has no effect.
Signed-off-by: David Sterba
---
fs/btrfs/super.c | 17 -
1 files changed, 4 insertions(+), 13 delet
Thanks for submitting this patch Jan, this patch has been committed.
Thanks
--Rich
commit cfe73f711eff55c374d9c0db8921089ec4ad8607
Author: Jan Schmidt
Date: Tue Mar 19 16:24:20 2013 +
xfstests: add background noise to test 276 (btrfs backref resolving)
--
To unsubscribe from this li
On Fri, Mar 15, 2013 at 03:12:41PM -0400, Josef Bacik wrote:
> I can't reproduce with btrfs-next or btrfs-next ontop of 3.9-rc2. Can you
> just
> patch out the skinny metadata patch and see if the problem still happens?
Quick test does not reproduce the problems with 3.9-rc3 + current next,
scru
> There is a missing dependency: liblzo2-dev
> I suggest to make amendment to the wiki and add a "liblzo2-dev" to the
> apt-get line for Ubuntu/Debian.
Added. Other distros may need some additions too.
Anyone can edit the wiki, as the spambots will attest; a ConfirmEdit
captcha at signup would
There is a missing dependency: liblzo2-dev
Without it, the make fails with:
~/tmp$ git clone
git://git.kernel.org/pub/scm/linux/kernel/git/mason/btrfs-progs.git
~/tmp$ cd btrfs-progs
~/tmp/btrfs-progs$ sudo apt-get install uuid-dev libattr1-dev zlib
1g-dev libacl1-dev e2fslibs-dev libblkid-
25 matches
Mail list logo
