This gives EXDEV for clone operations that btrfs could otherwise execute
and with slight change of circumstances will actually execute fine.
Imagine we have a btrfs on /dev/mapper/foobar with subvols /foo and
/bar. Let’s also imagine top of said fs in mounted at /mnt. In this
case, a
On 30.06.2013 05:17, Josef Bacik wrote:
We need to hold the tree mod log lock in __tree_mod_log_rewind since we walk
forward in the tree mod entries, otherwise we'll end up with random entries
and
trip the BUG_ON() at the front of __tree_mod_log_rewind. This fixes the
panics
people were
Hi Josef,
On Wed, Jun 26, 2013 at 5:16 PM, Alex Lyakas
alex.bt...@zadarastorage.com wrote:
Hi Josef,
Can you please help me with another question.
I am looking at your patch:
Btrfs: fix chunk allocation error handling
On Sun, Jun 30, 2013 at 10:25:05AM +0200, Jan Schmidt wrote:
On 30.06.2013 05:17, Josef Bacik wrote:
We need to hold the tree mod log lock in __tree_mod_log_rewind since we walk
forward in the tree mod entries, otherwise we'll end up with random entries
and
trip the BUG_ON() at the front
On Sun, Jun 30, 2013 at 11:29:14AM +0300, Alex Lyakas wrote:
Hi Josef,
On Wed, Jun 26, 2013 at 5:16 PM, Alex Lyakas
alex.bt...@zadarastorage.com wrote:
Hi Josef,
Can you please help me with another question.
I am looking at your patch:
Btrfs: fix chunk allocation error handling
1) add missing write check for mkfs
2) add kstrdup() return value check
3) remove unused code in btrfs_scan_one_device()
Filipe David Borba Manana (3):
Btrfs-progs: add missing write check for mkfs
Btrfs-progs: add kstrdup() return value check
Btrfs-progs: remove unused code in
When allocating a btrfs_device structure, device_list_add()
in volumes.c was not checking if the call to duplicate the
label string succeeded or not.
Signed-off-by: Filipe David Borba Manana fdman...@gmail.com
---
volumes.c |5 +
1 file changed, 5 insertions(+)
diff --git a/volumes.c
Assert that the write of the device tree root succeeds.
This verification is currently done for all other tree
roots, however it was missing for the device tree root.
Would this tree root write fail, but all others succeed,
it would lead to a corrupted/incomplete btrfs filesystem.
Signed-off-by:
The uuid_unparse() call in btrfs_scan_one_device() was
a no-op.
Signed-off-by: Filipe David Borba Manana fdman...@gmail.com
---
volumes.c |2 --
1 file changed, 2 deletions(-)
diff --git a/volumes.c b/volumes.c
index ea1d401..9d5e97e 100644
--- a/volumes.c
+++ b/volumes.c
@@ -223,7 +223,6
On Sun, Jun 30, 2013 at 10:25:05AM +0200, Jan Schmidt wrote:
On 30.06.2013 05:17, Josef Bacik wrote:
We need to hold the tree mod log lock in __tree_mod_log_rewind since we walk
forward in the tree mod entries, otherwise we'll end up with random entries
and
trip the BUG_ON() at the front
Hello,
I have 3 partitions with btrfs(/, /home and /data). All of them have following
mount options
noatime,space_cache,inode_cache,compress=lzo,defaults
Whenever there is a unclean shutdown(which happens a lot in my case), the next
reboot, system comes up relatively at the same speed but as
Hi
I'm now sucessfully backing up my ubuntu machine using btrfs send and
btrfs receive. Essentially I do
mount /dev/sda3 /mnt
cd /mnt
btrfs subvolume snapshot @ backups/@-backupNew
btrfs send -p backups/@-backupOld backups/@-backupNew | pv | btrfs
receive /media/miguel/huge/backups/@
This is
There's been a parallel effort to incorporate a general set of lz4
patches in the kernel.
I see these patches are currently queued up in the linux-next tree, so
we may see them in the 3.11 kernel.
It looks like lz4 and lz4hc will be provided.
So, instead of btrfs having it's own implementation
On 6-30-13 19:26:16 Shridhar Daithankar wrote:
Whenever there is a unclean shutdown(which happens a lot in my
case), the next reboot, system comes up relatively at the same speed
but as systemd is starting up daemons, the disk is continuously (and
unusally long) grinding.
[snip]
How can I
On Sun, Jun 30, 2013 at 11:02:10PM +0800, Liu Bo wrote:
On Sun, Jun 30, 2013 at 07:22:00AM -0400, Josef Bacik wrote:
On Sun, Jun 30, 2013 at 10:25:05AM +0200, Jan Schmidt wrote:
On 30.06.2013 05:17, Josef Bacik wrote:
We need to hold the tree mod log lock in __tree_mod_log_rewind since
On 06/30/2013 06:53 PM, Garry T. Williams wrote:
On 6-30-13 19:26:16 Shridhar Daithankar wrote:
Whenever there is a unclean shutdown(which happens a lot in my
case), the next reboot, system comes up relatively at the same speed
but as systemd is starting up daemons, the disk is continuously
Hi,
I suspect this is, at least in part, related to severe fragmentation
in /home.
In his cause those issues are only present after an unclean shutdown -
whereas fragmentation would show its effect after every reboot.
Regards, Clemens
--
To unsubscribe from this list: send the line
Garry T. Williams posted on Sun, 30 Jun 2013 13:53:48 -0400 as excerpted:
I suspect this is, at least in part, related to severe fragmentation in
/home.
There are large files in these directories that are updated frequently
by various components of KDE and the Chrome browser. (Firefox has
-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
On Sunday, June 30, 2013 01:53:48 PM Garry T. Williams wrote:
I suspect this is, at least in part, related to severe fragmentation
in /home.
I don't think so. The problem I have described occur only before anybody logs
in to the system and /home being a separate partition, it is not the
20 matches
Mail list logo
