Running a traditional raid5 array of that size is statistically
guaranteed to fail in the event of a rebuild. I also need to expand
the size of available storage to accomodate future storage
requirements. My understanding is that a Btrfs array is easily
expanded without the overhead associated with
On Fri, Aug 28, 2015 at 10:50:12AM +0200, George Duffield wrote:
> Running a traditional raid5 array of that size is statistically
> guaranteed to fail in the event of a rebuild.
Except that if it were, you wouldn't see anyone running RAID-5
arrays of that size and (considerably) larger. And su
On Fri, 28 Aug 2015 10:50:12 +0200
George Duffield wrote:
> Running a traditional raid5 array of that size is statistically
> guaranteed to fail in the event of a rebuild.
Yeah I consider RAID5 to be safe up to about 4 devices. As you already have 5
and looking to expand, I'd recommend going RAI
Austin S Hemmelgarn posted on Thu, 27 Aug 2015 08:01:58 -0400 as
excerpted:
>> Someone (IIRC it was Austin H) posted what I thought was an extremely
>> good setup, a few weeks ago. Create two (or more) mdraid0s, and put
>> btrfs raid1 (or raid5/6 when it's a bit more mature, I've been
>> recommen
After this system hangs.
dmesg log I am get through ssh and root user.
For /home partition used btrfs file system.
[174914.234404] INFO: task btrfs-transacti:753 blocked for more than
120 seconds.
[174914.234408] Not tainted 4.2.0-0.rc8.git0.1.fc23.x86_64+debug #1
[174914.234408] "echo 0 >
On 2015-08-28 05:47, Duncan wrote:
Austin S Hemmelgarn posted on Thu, 27 Aug 2015 08:01:58 -0400 as
excerpted:
Someone (IIRC it was Austin H) posted what I thought was an extremely
good setup, a few weeks ago. Create two (or more) mdraid0s, and put
btrfs raid1 (or raid5/6 when it's a bit more
On Wed, Aug 26, 2015 at 8:06 PM, Josef Bacik wrote:
> On 08/25/2015 10:06 PM, Liu Bo wrote:
>>
>> On Tue, Aug 25, 2015 at 01:09:43PM -0400, Josef Bacik wrote:
>>>
>>> If we have an fsync at the same time in two seperate subvolumes we could
>>> end up
>>> with the tree log pointing at invalid block
On 08/28/2015 09:23 AM, Filipe David Manana wrote:
On Wed, Aug 26, 2015 at 8:06 PM, Josef Bacik wrote:
On 08/25/2015 10:06 PM, Liu Bo wrote:
On Tue, Aug 25, 2015 at 01:09:43PM -0400, Josef Bacik wrote:
If we have an fsync at the same time in two seperate subvolumes we could
end up
with the
it was highlighted to me is_block_device(), returns
1 if the file is a block device,
< 0 in case of an error (eg: file not found)
0 otherwise
This patch makes proper return checks at all the places
where is_block_device() is used. Thanks to Goffredo.
Signed-off-by: Anand Jain
Suggested-by: Go
Hi Goffredo,
sorry to have missed this.
On 08/20/2015 07:29 PM, Goffredo Baroncelli wrote:
Hi Anand
On 2015-08-14 12:36, Anand Jain wrote:
This patch introduces new option for the command
[...]
+
+ if (is_numerical(argv[i])) {
+ argv3.devid = arg_str
On Friday 28 Aug 2015 10:10:54 Liu Bo wrote:
> On Thu, Aug 27, 2015 at 11:39:00PM +0530, Chandan Rajendra wrote:
> > The following call trace is seen when generic/095 test is executed,
> >
> > WARNING: CPU: 3 PID: 2769 at
> > /home/chandan/code/repos/linux/fs/btrfs/inode.c:8967
> > btrfs_destroy_i
I have noticed a BTRFS error mentioned in two consecutive identical entries in
my kernel log:
"BTRFS error (device sda2): bad extent! em: [0 0] passed [0 4096]"
sda2 contains a btrfs with skinny extents has been created a few days ago and
contains a few subvolumes (mounted as root and home) and
On Fri, Aug 28, 2015 at 9:10 AM, J - wrote:
> I have noticed a BTRFS error mentioned in two consecutive identical entries
> in my kernel log:
> "BTRFS error (device sda2): bad extent! em: [0 0] passed [0 4096]"
>
> sda2 contains a btrfs with skinny extents has been created a few days ago and
>
On 2015-08-28 11:10, J - wrote:
I have noticed a BTRFS error mentioned in two consecutive identical entries in
my kernel log:
"BTRFS error (device sda2): bad extent! em: [0 0] passed [0 4096]"
sda2 contains a btrfs with skinny extents has been created a few days ago and
contains a few subvolu
The following call trace is seen when generic/095 test is executed,
WARNING: CPU: 3 PID: 2769 at
/home/chandan/code/repos/linux/fs/btrfs/inode.c:8967
btrfs_destroy_inode+0x284/0x2a0()
Modules linked in:
CPU: 3 PID: 2769 Comm: umount Not tainted 4.2.0-rc5+ #31
Hardware name: QEMU Standard PC (i44
On Fri, Aug 28, 2015 at 3:35 AM, Hugo Mills wrote:
> On Fri, Aug 28, 2015 at 10:50:12AM +0200, George Duffield wrote:
>> Running a traditional raid5 array of that size is statistically
>> guaranteed to fail in the event of a rebuild.
>
>Except that if it were, you wouldn't see anyone running R
On 2015-08-28 16:17, Anand Jain wrote:
>
> Hi Goffredo,
>
> sorry to have missed this.
>
[...]
>
> In fact everywhere we didn't check the return properly.
> I wrote a new patch to fix this.
>
> Thanks, Anand
Many thanks for your work
BR
Goffredo
--
gpg @keyserver.linux.it: Goffredo Baron
On 2015-08-28 16:17, Anand Jain wrote:
>
> Hi Goffredo,
>
> sorry to have missed this.
>
[...]
>
> In fact everywhere we didn't check the return properly.
> I wrote a new patch to fix this.
>
> Thanks, Anand
Many thanks for your work
BR
Goffredo
--
gpg @keyserver.linux.it: Goffredo Baron
On 2015-08-28 11:42, Chris Murphy wrote:
On Fri, Aug 28, 2015 at 3:35 AM, Hugo Mills wrote:
On Fri, Aug 28, 2015 at 10:50:12AM +0200, George Duffield wrote:
Running a traditional raid5 array of that size is statistically
guaranteed to fail in the event of a rebuild.
Except that if it wer
On Thu, Aug 27, 2015 at 09:38:19PM +0800, Zhao Lei wrote:
> We are using separate code for parse unit mode in current code,
> result is each command have different argument for unit mode:
>
> # btrfs filesystem show --help
>...
>--raw raw numbers in bytes
>--human-readabl
On Fri, Aug 28, 2015 at 12:38:17AM +0900, Byongho Lee wrote:
> In btrfs-map-logical main(), strdup() allocates memory to output_file,
> but that memory is not freed.
> So add missing free() calls before return.
>
> Signed-off-by: Byongho Lee
Applied, thanks.
--
To unsubscribe from this list: sen
On Fri, Aug 28, 2015 at 12:38:18AM +0900, Byongho Lee wrote:
> In btrfs_add_to_fsid(), strdup() allocates memory to device->name, but
> the return value is not checked.
> So add the return value check and error handling code.
> And clean-up error handling code for ENOMEM case.
>
> Signed-off-by: B
On Fri, Aug 28, 2015 at 11:42:11AM +0800, Zhao Lei wrote:
> Current code have following bug for subvolume sync:
> 1: If there are more than 1 subvolume to sync, the program will
>infinitely loop.
> 2: return !0 in exit
>
> This patch add misc-tests/007-subvolume-sync for above case.
>
> Signe
On Fri, Aug 28, 2015 at 11:43:56AM +0800, Zhao Lei wrote:
> Add testcase filter for misc-tests, so we can select to run necessary
> test cases.
>
> For example:
> # ./misc-tests.sh 002
> [TEST] 002-uuid-rewrite
> #
> # ./misc-tests.sh subvolume
> [TEST] 007-subvolume-sync
> #
I'm
On Fri, Aug 28, 2015 at 11:49:39AM +0800, Zhao Lei wrote:
> If a testcase failed, we can't run it(or other tests needs mount) again,
My expectation is that the testsuite will not fail and if it does, I
wan't to keep the last stat so I can have a look. Would it be acceptable
for you to enhance the
On Thu, Aug 27, 2015 at 11:53:45PM +, Alexandru Moise wrote:
> Just call kmem_cache_zalloc() instead of calling kmem_cache_alloc().
> We're just initializing most fields to 0, false and NULL later on
> _anyway_, so to make the code mode readable and potentially gain
> a bit of performance (comp
I wanted to add one more tool for incremental backups to wiki, but
accidentally had typo in email at registration.
Now, more than one month after I still can't register, though
registration request should expire already.
Does anyone have access to fix that? Can't find any contacts of person
who
I wanted to add one more tool for incremental backups to wiki, but
accidentally had typo in email at registration.
Now, more than one month after I still can't register, though
registration request should expire already.
Does anyone have access to fix that? Can't find any contacts of person
who
On Fri, Aug 28, 2015 at 07:38:56PM +0200, David Sterba wrote:
> On Thu, Aug 27, 2015 at 11:53:45PM +, Alexandru Moise wrote:
> > Just call kmem_cache_zalloc() instead of calling kmem_cache_alloc().
> > We're just initializing most fields to 0, false and NULL later on
> > _anyway_, so to make th
29 matches
Mail list logo
