This reverts commit 2f0810880f082fa8ba66ab2c33b02e4ff9770a5e.
This tried to fix the following test case:
mkfs.ext4 -F /dev/sda
btrfs-convert /dev/sda
mount /dev/sda /mnt
btrfs device add -f /dev/sdb /mnt
btrfs balance start -v -dconvert=raid1
On Sun, 19 Apr 2015 14:46:28 +0300
Lauri Võsandi lauri.vosa...@gmail.com wrote:
This patch forces btrfs receive to issue chroot before
parsing the btrfs stream using command-line flag -C
to confine the process and minimize damage that could
be done via malicious btrfs stream.
On 4/17/2015 at 10:36 PM, Holger Hoffstaette
holger.hoffstae...@googlemail.com wrote:
I don't know about the device stats, but at least the log level for
read errors was already fixed in a patch series:
http://www.spinics.net/lists/linux-btrfs/msg40556.html
This was merged into 4.0.
Thanks!
On 18 April 2015 at 14:59, Lauri Võsandi lauri.vosa...@gmail.com wrote:
This patch forces btrfs receive to issue chroot before
parsing the btrfs stream using command-line flag -C
to confine the process and minimize damage that could
be done via malicious btrfs stream.
Signed-off-by: Lauri
This patch forces btrfs receive to issue chroot before
parsing the btrfs stream using command-line flag -C
to confine the process and minimize damage that could
be done via malicious btrfs stream.
Signed-off-by: Lauri Võsandi lauri.vosa...@gmail.com
---
cmds-receive.c | 38
Hi all
I'm looking into the advisability of running PostgreSQL on BTRFS, and
after looking at the FAQ there's something I'm hoping you could
clarify.
The wiki FAQ says:
Btrfs does not force all dirty data to disk on every fsync or O_SYNC
operation, fsync is designed to be fast.
Is that wording
Hi, this is David Wu from Shanghai, China.
Please let me know if you need color box, display box, corrugated box,
label, hang tag etc.
I will send you the website.
Best regards,
David Wu
--
To unsubscribe from this list: send the line unsubscribe linux-btrfs in
the body of a message to
On Sun, Apr 19, 2015 at 07:50:32PM +0200, Martin Steigerwald wrote:
Am Sonntag, 19. April 2015, 15:18:51 schrieb Hugo Mills:
On Sun, Apr 19, 2015 at 05:10:30PM +0200, Martin Steigerwald wrote:
Am Sonntag, 19. April 2015, 22:31:02 schrieb Craig Ringer:
I'm curious as to whether +C has any
Hi all, We have recently had major issues with our large btrfs volume
crashing and remounting read-only because it thinks it's out of space.
The volume is 55TB on h/w raid 6 with 44TB free and the server is
running Ubuntu 14.04 server x64. The problem first happened with kernel
3.13 but I've
Am Sonntag, 19. April 2015, 15:18:51 schrieb Hugo Mills:
On Sun, Apr 19, 2015 at 05:10:30PM +0200, Martin Steigerwald wrote:
Am Sonntag, 19. April 2015, 22:31:02 schrieb Craig Ringer:
On 19 April 2015 at 22:28, Martin Steigerwald mar...@lichtvoll.de
wrote:
Am Sonntag, 19. April
Am Sonntag, 19. April 2015, 18:18:24 schrieb Hugo Mills:
On Sun, Apr 19, 2015 at 07:50:32PM +0200, Martin Steigerwald wrote:
Am Sonntag, 19. April 2015, 15:18:51 schrieb Hugo Mills:
On Sun, Apr 19, 2015 at 05:10:30PM +0200, Martin Steigerwald wrote:
Am Sonntag, 19. April 2015, 22:31:02
On Sat, Apr 18, 2015 at 10:36 AM, Kai Krakow hurikha...@gmail.com wrote:
I wonder if one could split mirrors in btrfs... Read:
btrfs device add the new device, set the raid policy for data, meta data,
and system to raid-1, balance, and then unmount and detach one of the
devices.
I'm not
On Sun, Apr 19, 2015 at 08:41:39PM +0200, Martin Steigerwald wrote:
Am Sonntag, 19. April 2015, 18:18:24 schrieb Hugo Mills:
On Sun, Apr 19, 2015 at 07:50:32PM +0200, Martin Steigerwald wrote:
Am Sonntag, 19. April 2015, 15:18:51 schrieb Hugo Mills:
On Sun, Apr 19, 2015 at 05:10:30PM
On Sun, 2015-04-19 at 01:02 +1000, Russell Coker wrote:
An rsync on block devices wouldn't lose BTRFS checksums, you could run a
scrub
on the target at any time to verify them. For a dd or anything based on that
the target needs to be at least as big as the source. But typical use of
On Sun, Apr 19, 2015 at 05:10:30PM +0200, Martin Steigerwald wrote:
Am Sonntag, 19. April 2015, 22:31:02 schrieb Craig Ringer:
On 19 April 2015 at 22:28, Martin Steigerwald mar...@lichtvoll.de
wrote:
Am Sonntag, 19. April 2015, 21:20:11 schrieb Craig Ringer:
Hi all
Hi Craig,
On 19 April 2015 at 22:28, Martin Steigerwald mar...@lichtvoll.de wrote:
Am Sonntag, 19. April 2015, 21:20:11 schrieb Craig Ringer:
Hi all
Hi Craig,
I'm looking into the advisability of running PostgreSQL on BTRFS, and
after looking at the FAQ there's something I'm hoping you could
Am Sonntag, 19. April 2015, 22:31:02 schrieb Craig Ringer:
On 19 April 2015 at 22:28, Martin Steigerwald mar...@lichtvoll.de
wrote:
Am Sonntag, 19. April 2015, 21:20:11 schrieb Craig Ringer:
Hi all
Hi Craig,
I'm looking into the advisability of running PostgreSQL on BTRFS, and
While the discussion on -C was interesting, I'm really interested in
btrfs's fsync() behaviour, per the original post:
On 19 April 2015 at 21:20, Craig Ringer cr...@2ndquadrant.com wrote:
Hi all
I'm looking into the advisability of running PostgreSQL on BTRFS, and
after looking at the FAQ
On Fri, 10 Apr 2015 11:24:31 +1000 NeilBrown ne...@suse.de wrote:
On Thu, 09 Apr 2015 10:23:08 +0100 David Howells dhowe...@redhat.com wrote:
NeilBrown ne...@suse.de wrote:
Is there a better way? Could a better way be created? Maybe
SEEK_DATA_RELIABLE ??
fiemap() maybe?
Christoph Anton Mitterer posted on Sun, 19 Apr 2015 22:00:24 +0200 as
excerpted:
Most of the time, only one of the two disks shows activity, while the
other is reading respectively writing.
The CPU isn't really under full load either (not even a single core),...
it's rather in the 5-10%
This allows fscache to cachefiles in a btrfs filesystem.
Signed-off-by: NeilBrown ne...@suse.de
---
fs/btrfs/super.c |3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/fs/btrfs/super.c b/fs/btrfs/super.c
index 05fef198ff94..d3c5d2b40f8e 100644
--- a/fs/btrfs/super.c
+++
From: George Wang xuw2...@gmail.com
PPC64 arch use such following IOC values
\#define _IOC_NONE 1U
\#define _IOC_READ 2U
\#define _IOC_WRITE 4U
comparing to the default IOC values
\#define _IOC_NONE 0U
\#define _IOC_READ 2U
\#define _IOC_WRITE 1U
This means
On 2015/04/20 5:15, Joel Best wrote:
Hi all, We have recently had major issues with our large btrfs volume crashing
and remounting read-only because it thinks it's out of space. The volume is
55TB on h/w raid 6 with 44TB free and the server is running Ubuntu 14.04 server
x64. The problem
On 2015/04/20 13:08, Tsutomu Itoh wrote:
On 2015/04/20 5:15, Joel Best wrote:
Hi all, We have recently had major issues with our large btrfs volume crashing
and remounting read-only because it thinks it's out of space. The volume is
55TB on h/w raid 6 with 44TB free and the server is running
On Sun, Apr 19, 2015 at 10:31:02PM +0800, Craig Ringer wrote:
On 19 April 2015 at 22:28, Martin Steigerwald mar...@lichtvoll.de wrote:
Am Sonntag, 19. April 2015, 21:20:11 schrieb Craig Ringer:
Hi all
Hi Craig,
I'm looking into the advisability of running PostgreSQL on BTRFS, and
The following three patches allow fs to cachefiles in a BTRFS
filesystem.
The first is a minor cleanup to cachefiles.
The second is the main change - it teaches cachefile to use
lseek(SEEK_DATA) to find allocated blocks in a file, rather than bmap.
The third patch simply enables this for btrfs.
cachefiles currently uses 'bmap' to determine if a given block
in a file has been cached, or not.
Not all filesystems support bmap, particularly BTRFS.
SEEK_DATA can be used to determine if a block in a file has
been allocated, but not all filesystems support this reliably.
On filesystems without
cachefiles requires that s_blocksize in the cache is not greater than
PAGE_SIZE, and performs the check every time a block is accessed.
Move the test to the place where the file is opened, where other
file-validity tests are performed.
Signed-off-by: NeilBrown ne...@suse.de
---
Am Sonntag, 19. April 2015, 21:20:11 schrieb Craig Ringer:
Hi all
Hi Craig,
I'm looking into the advisability of running PostgreSQL on BTRFS, and
after looking at the FAQ there's something I'm hoping you could
clarify.
The wiki FAQ says:
Btrfs does not force all dirty data to disk on
On Mon, 20 Apr 2015, Craig Ringer cr...@2ndquadrant.com wrote:
PostgreSQL is its self copy-on-write (because of multi-version
concurrency control), so it doesn't make much sense to have the FS
doing another layer of COW.
That's a matter of opinion.
I think it's great if PostgreSQL can do
30 matches
Mail list logo
