On Sun, 9 Mar 2014 03:30:44 PM Duncan wrote:
While I realize that was in reference to the up in flames comment and
presumably if there's a need to worry about that, offsite backup /is/ of
some value, for some people, offsite backup really isn't that valuable.
Actually I missed that comment
On Mon, Mar 03, 2014 at 11:56:49AM -0600, thanumalayan mad wrote:
Chris,
Great, thanks. Any guesses whether other filesystems (disk-based) do
things similar to the last two examples you pointed out? Saying we
think 3 normal filesystems reorder stuff seems to motivate
application developers
Hi Dave,
On 03/13/2014 12:21 AM, David Sterba wrote:
On Tue, Mar 11, 2014 at 06:29:09PM +0800, Wang Shilong wrote:
@@ -840,6 +833,10 @@ static int traverse_directory(struct btrfs_trans_handle
*trans,
cur_file-d_name, cur_inum,
Regression test for btrfs incremental send issue where a rmdir instruction
is sent against an orphan directory inode which is not empty yet, causing
btrfs receive to fail when it attempts to remove the directory.
This issue is fixed by the following linux kernel btrfs patch:
Btrfs: fix send
Regression test for a btrfs incremental send issue where invalid paths for
utimes, chown and chmod operations were sent to the send stream, causing
btrfs receive to fail.
If a directory had a move/rename operation delayed, and none of its parent
directories, except for the immediate one, had
On 03/13/2014 01:19 AM, Wang Shilong wrote:
We hit something like the following function call flows:
|-run_delalloc_range()
|-btrfs_join_transaction()
|-cow_file_range()
|-btrfs_join_transaction()
|-find_free_extent()
|-btrfs_join_transaction()
Trace infomation
Previously, the no-op mount -o mount /dev/xxx operation when the
file system is already mounted read-write causes an implied,
unconditional syncfs(). This seems pretty stupid, and it's certainly
documented or guaraunteed to do this, nor is it particularly useful,
except in the case where the file
On Thu 13-03-14 10:20:56, Ted Tso wrote:
Previously, the no-op mount -o mount /dev/xxx operation when the
^^remount
file system is already mounted read-write causes an implied,
unconditional syncfs(). This seems pretty stupid, and it's certainly
documented
Hi,
On Thu, 2014-03-13 at 17:23 +0100, Jan Kara wrote:
On Thu 13-03-14 10:20:56, Ted Tso wrote:
Previously, the no-op mount -o mount /dev/xxx operation when the
^^remount
file system is already mounted read-write causes an implied,
unconditional
On Mar 7, 2014, at 7:03 AM, Eric Mesa ericsbinarywo...@gmail.com wrote:
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
On 03/10/2014 06:02 PM, Avi Miller wrote:
Oracle Linux 6 with the Unbreakable Enterprise Kernel Release 2 or Release 3
has production-ready btrfs support. You can even convert your existing CentOS6
boxes across to Oracle Linux 6 in-place without reinstalling:
My backup use case is different from the what has been recently
discussed in another thread. I'm trying to guard against hardware
failure and other causes of destruction.
I have a btrfs raid1 filesystem spread over two disks. I want to backup
this filesystem regularly and efficiently to an
On Thu, Mar 13, 2014 at 08:12:44PM +0100, Michael Schuerig wrote:
My backup use case is different from the what has been recently
discussed in another thread. I'm trying to guard against hardware
failure and other causes of destruction.
I have a btrfs raid1 filesystem spread over two
Lets try this again. We can deadlock the box if we send on a box and try to
write onto the same fs with the app that is trying to listen to the send pipe.
This is because the writer could get stuck waiting for a transaction commit
which is being blocked by the send. So fix this by making sure
Hi,
On 14 Mar 2014, at 5:10 am, Lists li...@benjamindsmith.com wrote:
Is there any issue with BTRFS and 32 bit O/S like with ZFS?
We provide some btrfs support with the 32-bit UEK Release 2 on OL6, but we
strongly recommend only using the UEK Release 3 which is 64-bit only.
--
Oracle
On Thursday 13 March 2014 14:48:55 Andrew Skretvedt wrote:
On 2014-Mar-13 14:28, Hugo Mills wrote:
On Thu, Mar 13, 2014 at 08:12:44PM +0100, Michael Schuerig wrote:
My backup use case is different from the what has been recently
discussed in another thread. I'm trying to guard against
On Mar 13, 2014, at 3:14 PM, Michael Schuerig michael.li...@schuerig.de wrote:
On Thursday 13 March 2014 14:48:55 Andrew Skretvedt wrote:
On 2014-Mar-13 14:28, Hugo Mills wrote:
On Thu, Mar 13, 2014 at 08:12:44PM +0100, Michael Schuerig wrote:
My backup use case is different from the what
On Thu, Mar 13, 2014 at 03:42:13PM -0400, Josef Bacik wrote:
Lets try this again. We can deadlock the box if we send on a box and try to
write onto the same fs with the app that is trying to listen to the send pipe.
This is because the writer could get stuck waiting for a transaction commit
On Thursday 13 March 2014 16:04:33 Chris Murphy wrote:
On Mar 13, 2014, at 3:14 PM, Michael Schuerig
michael.li...@schuerig.de wrote:
On Thursday 13 March 2014 14:48:55 Andrew Skretvedt wrote:
On 2014-Mar-13 14:28, Hugo Mills wrote:
On Thu, Mar 13, 2014 at 08:12:44PM +0100, Michael
On Thu, Mar 13, 2014 at 04:28:23PM +, Steven Whitehouse wrote:
I guess the same is true for other file systems which are mounted ro
too. So maybe a check for MS_RDONLY before doing the sync in those
cases?
My original patch moved the sync_filesystem into the check for
MS_RDONLY in the
See comments at the bottom:
On 03/13/2014 05:29 PM, George Mitchell wrote:
On 03/13/2014 04:03 PM, Michael Schuerig wrote:
On Thursday 13 March 2014 16:04:33 Chris Murphy wrote:
On Mar 13, 2014, at 3:14 PM, Michael Schuerig
michael.li...@schuerig.de wrote:
On Thursday 13 March 2014 14:48:55
Can anyone comment on this.
Are others seeing some btrfs operations on filesystem/diskA hang/deadlock
other btrfs operations on filesystem/diskB ?
I just spent time fixing near data corruption in one of my systems due to
a 7h delay between when the timestamp was written and the actual data was
In btrfs_scan_lblkid(), blkid_get_cache() is called but cache not freed.
This patch adds blkid_put_cache() to free it.
Signed-off-by: Qu Wenruo quwen...@cn.fujitsu.com
---
utils.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/utils.c b/utils.c
index 93cf9ac..b809bc5 100644
--- a/utils.c
Valgrind reports memleak in btrfs_scan_one_device() about allocating
btrfs_device but on btrfs_close_devices() they are not reclaimed.
Although not a bug since after btrfs_close_devices() btrfs will exit so
memory will be reclaimed by system anyway, it's better to fix it anyway.
Signed-off-by:
On Mar 13, 2014, at 7:14 PM, Lists li...@benjamindsmith.com wrote:
I'm assuming that BTRFS send/receive works similar to ZFS's similarly named
feature.
Similar yes but not all options are the same between them. e.g. zfs send -R
replicates all descendent file systems. I don't think zfs
On Mar 13, 2014, at 8:11 PM, Marc MERLIN m...@merlins.org wrote:
On Sun, Mar 09, 2014 at 11:33:50AM +, Hugo Mills wrote:
discard is, except on the very latest hardware, a synchronous command
(it's a limitation of the SATA standard), and therefore results in
very very poor performance.
Marc MERLIN posted on Thu, 13 Mar 2014 18:48:13 -0700 as excerpted:
Are others seeing some btrfs operations on filesystem/diskA
hang/deadlock other btrfs operations on filesystem/diskB ?
Well, if the filesystem in filesystem/diskA and filesystem/diskB is the
same (multi-device) filesystem, as
On Thu, Mar 13, 2014 at 09:39:02PM -0600, Chris Murphy wrote:
On Mar 13, 2014, at 8:11 PM, Marc MERLIN m...@merlins.org wrote:
On Sun, Mar 09, 2014 at 11:33:50AM +, Hugo Mills wrote:
discard is, except on the very latest hardware, a synchronous command
(it's a limitation of the SATA
28 matches
Mail list logo
