Thank you Hugo! Amazing. It almost work all the way,
According to some tests I did, echo 2 >/proc/cpu/alignment does allow in
fact btrfs receive to work in most cases. For the tests, a x86_64 for
send, a armv5tel for receive and 2 subvolumes (one with just a few
data and binary files and the
On Tue, Aug 19, 2014 at 06:21:52PM +0200, M G Berberich wrote:
> · incremental send/receive works.
Yes.
> · There is no support for hotspares (spare disks that automatically
> replaces faulty disk).
Correct
> · BtrFS with RAID1 is fairly stable.
>From what I know.
> · RAID 5/6 spreads all
On Tue, Aug 19, 2014 at 10:28:54AM -0700, Zach Brown wrote:
> On Tue, Aug 19, 2014 at 11:32:16AM +0800, Eryu Guan wrote:
> > Hi,
> >
> > Description of the problem:
> >
> > mount btrfs with selinux context, then create a subvolume, the new
> > subvolume cannot be mounted, even with the same conte
On 15/08/2014 12:30, Eryu Guan wrote:
On Fri, Aug 15, 2014 at 09:50:34AM +0800, Anand Jain wrote:
Eryu,
btrfs dev scan -d option is there for legacy reasons. The new method
is using libblkid to find btrfs devs.
David/Zach, is it time to remove -d option ? or mention deprecated.
Original Message
Subject: Re: [PATCH] btrfs: Don't continue mounting when superblock csum
mismatches even generation is less than 10.
From: Chris Mason
To: Qu Wenruo ,
Date: 2014年08月20日 03:48
On 08/06/2014 10:51 PM, Qu Wenruo wrote:
It seems that the patch is rejected in p
reproducer:
mount /dev/sdb /btrfs
btrfs dev add /dev/sdc /btrfs
btrfs rep start -B /dev/sdb /dev/sdd /btrfs
umount /btrfs
WARNING: CPU: 0 PID: 12661 at fs/btrfs/volumes.c:891
__btrfs_close_devices+0x1b0/0x200 [btrfs]()
::
__btrfs_close_devices()
::
WARN_ON(fs_devices->open_devices);
Aft
we are assigning number_devices to the total_bytes,
that's very confusing for a moment
Signed-off-by: Anand Jain
---
v2: accepts David comment renames ret_sz to tmp
fs/btrfs/volumes.c | 10 +-
1 file changed, 5 insertions(+), 5 deletions(-)
diff --git a/fs/btrfs/volumes.c b/fs/btrfs/vo
Original Message
Subject: Re: [PATCH] btrfs: Don't continue mounting when superblock csum
mismatches even generation is less than 10.
From: David Sterba
To: Qu Wenruo
Date: 2014年08月20日 01:18
On Thu, Aug 07, 2014 at 10:51:15AM +0800, Qu Wenruo wrote:
It seems that the patch
On Tue, Aug 19, 2014 at 03:10:55PM -0700, Zach Brown wrote:
> On Sun, Aug 17, 2014 at 02:44:34PM +0200, Klaus Holler wrote:
> > Hello list,
> >
> > I want to use an ARM kirkwood based NSA325v2 NAS (dubbed "Receiver") for
> > receiving btrfs snapshots done on several hosts, e.g. a Core Duo laptop
>
On Sun, Aug 17, 2014 at 02:44:34PM +0200, Klaus Holler wrote:
> Hello list,
>
> I want to use an ARM kirkwood based NSA325v2 NAS (dubbed "Receiver") for
> receiving btrfs snapshots done on several hosts, e.g. a Core Duo laptop
> running kubuntu 14.04 LTS (dubbed "Source"), storing them on a 3TB WD
On Tue, 19 Aug 2014 18:21:52 +0200
M G Berberich wrote:
> · BtrFS with RAID1 is fairly stable.
Maybe, but it's not optimized for performance: reads are not balanced in the
most optimal way, and writes may end up being submitted sequentially rather
than in parallel to two devices, resulting in wr
On 8/19/14, 10:33 AM, Liu Bo wrote:
> The crash is
>
> [ cut here ]
> kernel BUG at fs/btrfs/extent_io.c:2124!
> [...]
> Workqueue: btrfs-endio normal_work_helper [btrfs]
> RIP: 0010:[] []
> end_bio_extent_readpage+0xb45/0xcd0 [btrfs]
>
> This is in fact a regression.
I
Hi,
On 08/19/2014 06:21 PM, M G Berberich wrote:> · Are there any
reports/papers/web-pages about BtrFS-systems this size
> in use? Praises, complains, performance-reviews, whatever…
I don't know about papers or benchmarks but few weeks ago there was a
guy who has problem with really long mounti
On Tue, Aug 19, 2014 at 11:21 AM, M G Berberich
wrote:
> Hello,
>
> we are thinking about using BtrFS on standard hardware for a
> fileserver with about 50T (100T raw) of storage (25×4TByte).
>
I would recommend carefully reading this thread titled: "1 week to
rebuid 4x 3TB raid10 is a long time!
On 08/19/2014 11:33 AM, Liu Bo wrote:
> The crash is
>
> [ cut here ]
> kernel BUG at fs/btrfs/extent_io.c:2124!
> [...]
> Workqueue: btrfs-endio normal_work_helper [btrfs]
> RIP: 0010:[] []
> end_bio_extent_readpage+0xb45/0xcd0 [btrfs]
>
> This is in fact a regression
On 08/06/2014 10:51 PM, Qu Wenruo wrote:
> It seems that the patch is rejected in patchwork,
>
> Could any one tell me the reason?
I had nack'd it because I was worried at the time about the super crc
errors that Dave had found in the past. Sorry, I really thought I had
sent email about it.
But
On 08/19/2014 11:32 AM, Liu Bo wrote:
> We've defined a 'offset' out of bio_for_each_segment_all.
This isn't causing problems though? It should just be shadowing the
bio_for_each_segment_all variable for the duration of the curlies.
No objection as a cleanup, just making sure I'm not missing som
On 2014-08-19 12:21, M G Berberich wrote:
> Hello,
>
> we are thinking about using BtrFS on standard hardware for a
> fileserver with about 50T (100T raw) of storage (25×4TByte).
>
> This is what I understood so far. Is this right?
>
> · incremental send/receive works.
>
> · There is no support
On Sun, Jul 27, 2014 at 10:53:04PM -0400, Austin S Hemmelgarn wrote:
> >>> But, for right now I'd prefer the admin get involved in using the backup
> >>> supers. I think silently using the backups is going to lead to
> >>> surprises.
> >> Maybe there could be a mount non-default mount-option to us
On Tue, Aug 19, 2014 at 11:32:16AM +0800, Eryu Guan wrote:
> Hi,
>
> Description of the problem:
>
> mount btrfs with selinux context, then create a subvolume, the new
> subvolume cannot be mounted, even with the same context.
>
> mkfs -t btrfs /dev/sda5
> mount -o context=system_u:object_r:nfs_
My miss. Thank you all for pointing out that actually ext4 performed much worse
in this test. I am wondering whether there is some benchmarking has been done
in all sorts of different workloads with comparison to ext4. I know btrfs vs
ext4 is not the apple to apple test, but it will encourage us
On Thu, Aug 07, 2014 at 10:51:15AM +0800, Qu Wenruo wrote:
> It seems that the patch is rejected in patchwork,
It was not me :)
> Could any one tell me the reason?
I'd understand that the patch is no longer needed after the original
problem went away, but it's not what you describe in your chang
> · Besides using bcache, are there any possibilities to boost
> performance by adding (dedicated) cache-SSDs to a BtrFS?
dm-cache is in the mainline kernel and lvm2 recently added support to
make devicemapper configuration automatic. In my opinion, dm-cache is
a little easier to use because yo
On Mon, Jul 07, 2014 at 09:54:53AM +0800, Gui Hecheng wrote:
> The new option -f will force to do dangerous changes.
> e.g. clear the seeding flag.
missing signed-off-by
> --- a/Documentation/btrfstune.txt
> +++ b/Documentation/btrfstune.txt
> @@ -24,7 +24,8 @@ Enable seeding forces a fs readonly
Hello,
we are thinking about using BtrFS on standard hardware for a
fileserver with about 50T (100T raw) of storage (25×4TByte).
This is what I understood so far. Is this right?
· incremental send/receive works.
· There is no support for hotspares (spare disks that automatically
replaces faul
No problem =).
Then, just ignore patch.
2014-08-19 17:03 GMT+03:00 David Sterba :
> On Mon, Aug 11, 2014 at 03:17:11AM +0300, Timofey Titovets wrote:
>> According to https://btrfs.wiki.kernel.org/index.php/Project_ideas#btrfs
>> Quote:
>> merge functionality of btrfstune, eg. under btrfs dev set-s
On Wed, Aug 13, 2014 at 02:24:20PM +0800, Anand Jain wrote:
> reproducer:
> mount /dev/sdb /btrfs
> btrfs dev add /dev/sdc /btrfs
> btrfs rep start -B /dev/sdb /dev/sdd /btrfs
> umount /btrfs
>
> WARNING: CPU: 0 PID: 12661 at fs/btrfs/volumes.c:891
> __btrfs_close_devices+0x1b0/0x200 [btrfs]()
>
On Wed, Aug 13, 2014 at 02:24:26PM +0800, Anand Jain wrote:
> we are assigning number_devices to the total_bytes,
> that's very confusing for a moment
>
> Signed-off-by: Anand Jain
> ---
> fs/btrfs/volumes.c | 10 +-
> 1 file changed, 5 insertions(+), 5 deletions(-)
>
> diff --git a/fs/
The crash is
[ cut here ]
kernel BUG at fs/btrfs/extent_io.c:2124!
[...]
Workqueue: btrfs-endio normal_work_helper [btrfs]
RIP: 0010:[] []
end_bio_extent_readpage+0xb45/0xcd0 [btrfs]
This is in fact a regression.
It is because we forgot to increase @offset properly in r
We've defined a 'offset' out of bio_for_each_segment_all.
This is just a clean rename, no function changes.
Signed-off-by: Liu Bo
---
fs/btrfs/extent_io.c | 8
1 file changed, 4 insertions(+), 4 deletions(-)
diff --git a/fs/btrfs/extent_io.c b/fs/btrfs/extent_io.c
index 3af4966..7e27b
On 8/19/14, 10:10 AM, David Sterba wrote:
> On Mon, Aug 11, 2014 at 10:05:52AM -0700, Eric Sandeen wrote:
>> (What seems to be missing, though, is why would the user ever choose to use
>> '-d?')
>
> That's a fallback method if blkid or udev are not available. We've had
> reports in the past that
On 08/18/2014 05:42 PM, Mark Fasheh wrote:
> On Sun, Aug 17, 2014 at 03:09:21PM -0500, Eric Sandeen wrote:
>> Coverity pointed this out; in the newly added
>> qgroup_subtree_accounting(), if btrfs_find_all_roots()
>> returns an error, we leak at least the parents pointer,
>> and possibly the root
On Mon, Aug 11, 2014 at 06:13:03PM +0900, Satoru Takeuchi wrote:
> From: Satoru Takeuchi
>
> Current btrfs doesn't display any error message if this command
> failed to find any btrfs filesystem corresponding to
> ||| which user specified.
I'm not sure if it is necessary to print anything. Like
On Mon, Aug 11, 2014 at 10:05:52AM -0700, Eric Sandeen wrote:
> (What seems to be missing, though, is why would the user ever choose to use
> '-d?')
That's a fallback method if blkid or udev are not available. We've had
reports in the past that this functionality should not be dropped.
--
To unsu
On Tue, Aug 12, 2014 at 05:06:01PM +0900, Satoru Takeuchi wrote:
> +By default, the show command scans all devices found in /proc/partitions.
The default scanning method is blkid, /proc/partitions used to be the
default before that. Scanning /proc/partitions is not done through the
'show' command,
On 08/19/2014 10:23 AM, David Sterba wrote:
> On Tue, Aug 19, 2014 at 07:58:20PM +0800, Fengguang Wu wrote:
>> We noticed an xfstests failure on commit
>>
>> 8d875f95da43c6a8f18f77869f2ef26e9594fecc ("btrfs: disable strict file
>> flushes for renames and truncates")
>>
>> It's 100% reproducible in
On Mon, Aug 11, 2014 at 03:09:35AM +0100, Filipe Manana wrote:
> + if (name_len + data_len > buf_len) {
> + buf_len = name_len + data_len;
> + if (is_vmalloc_addr(buf)) {
> + vfree(buf);
> +
On Tue, Aug 19, 2014 at 07:58:20PM +0800, Fengguang Wu wrote:
> We noticed an xfstests failure on commit
>
> 8d875f95da43c6a8f18f77869f2ef26e9594fecc ("btrfs: disable strict file flushes
> for renames and truncates")
>
> It's 100% reproducible in the 5 test runs.
Same here, different mkfs confi
On Mon, Aug 11, 2014 at 03:17:11AM +0300, Timofey Titovets wrote:
> According to https://btrfs.wiki.kernel.org/index.php/Project_ideas#btrfs
> Quote:
> merge functionality of btrfstune, eg. under btrfs dev set-seed /dev/
> (discuss the command name though)
I've added this project idea long time ag
On Thu, Aug 07, 2014 at 10:35:59AM +0800, Gui Hecheng wrote:
> The close_ctree always returns 0 and the stuff that depends on
> its return value is of no sense.
> Just make close_ctree return void.
You should not do that if the function contains BUG_ONs, this means the
error path is not handled, r
Hi Chris,
We noticed an xfstests failure on commit
8d875f95da43c6a8f18f77869f2ef26e9594fecc ("btrfs: disable strict file flushes
for renames and truncates")
It's 100% reproducible in the 5 test runs.
test case: snb-drag/xfstests/4HDD-btrfs-generic-mid
27b9a8122ff71a8 8d875f95da43c6a8f18f7786
Hi stable team,
please add the following patches to stable trees.
Patch #3 applies to all currently live stables, a 7 years old bug. I've
briefly reviewed all 3 patches against 3.10/12/14/16 (ie. 3.4 skips #1
and #2).
Subjects:
Btrfs: read lock extent buffer while walking backrefs
42 matches
Mail list logo
