(thanks for the off-ML emails from the people who helped me
to understand).
Dave,
looks like you are suggesting something like..
---
+_dmerror_mount_options()
+{
+ _scratch_options mount
+ echo $SCRATCH_OPTIONS $MOUNT_OPTIONS $SELINUX_MOUNT_OPTIONS \
+
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_strtou64(argv[i]);
> + its_num = true;
> + } else if (is_block_dev
On 2015-08-18 17:09, Chris Murphy wrote:
On Tue, Aug 18, 2015 at 5:21 AM, Austin S Hemmelgarn
wrote:
On 2015-08-17 14:52, Timothy Normand Miller wrote:
I'm not sure if I'm doing this wrong. Here's what I'm seeing:
# btrfs-image -c9 -t4 -w /mnt/btrfs ~/btrfs_dump.z
Superblock bytenr is large
On 2015-08-18 22:55, Timothy Normand Miller wrote:
On Tue, Aug 18, 2015 at 10:48 PM, Qu Wenruo wrote:
Timothy Normand Miller wrote on 2015/08/18 22:46 -0400:
On Tue, Aug 18, 2015 at 9:32 PM, Qu Wenruo
wrote:
Hi Timothy,
Although I have replied to the bugzilla, IMHO it's more appropriate
On 2015-08-19 13:24, Tyler Bletsch wrote:
Thanks. I'd consider raid6, but since I'll be backing up to a second
btrfs raid5 array, I think I have sufficient redundancy, since
equivalent to raid 5+1 on paper. I'm doing that rather than something
like raid10 in a single box because I want the redun
On 2015-08-20 07:52, Austin S Hemmelgarn wrote:
On 2015-08-19 13:24, Tyler Bletsch wrote:
Thanks. I'd consider raid6, but since I'll be backing up to a second
btrfs raid5 array, I think I have sufficient redundancy, since
equivalent to raid 5+1 on paper. I'm doing that rather than something
lik
On 2015-08-20 00:40, Jonathan Panozzo wrote:
Zhao,
Thank you for your response. Two quick follow-up questions:
1: What happens on an unrecoverable data error case? Does the volume get put
into read-only mode?
Yes.
2: Out of curiosity, why is data checksumming tied to COW?
There's no saf
On Thu, Aug 20, 2015 at 7:38 AM, Austin S Hemmelgarn
wrote:
> Just for reference, I've found that it is usually safer to delete the
> missing device first if possible, then add the new one and re-balance. There
> seem to be some edge-cases in the code for deleting missing devices.
>
The problem
On 2015-08-20 09:08, Timothy Normand Miller wrote:
On Thu, Aug 20, 2015 at 7:38 AM, Austin S Hemmelgarn
wrote:
Just for reference, I've found that it is usually safer to delete the
missing device first if possible, then add the new one and re-balance. There
seem to be some edge-cases in the co
Thanks for looking, let me know if you need any other info. I haven't
touched the system yet, but it appears I'll need to unmount to btrfs
check or mount rw,recovery to try and get it working again. Who knows
what will happen then? I can leave it as if for a few days if it will
help any diagnosis.
On Wed, Aug 19, 2015 at 9:43 PM, Russell Coker wrote:
> On Thu, 20 Aug 2015 11:55:43 AM Chris Murphy wrote:
>> > Question 1: If I apply the NOCOW attribute to a file or directory, how
>> > does that affect my ability to run btrfs scrub?
>>
>> nodatacow includes nodatasum and no compression. So it
Hi,
I want to "soft" mirroring between two remote btrfs volumes.
I tried to use btrfs send/receive instead of rsync
(because rsync to btrfs volume freeze btrfs
http://www.spinics.net/lists/linux-btrfs/msg44695.html)
But it failed everytime.
1st ) Pipe with SSH, to fresh filesystem. sender was fl
On 2015-08-20 12:44, Chris Murphy wrote:
On Wed, Aug 19, 2015 at 9:43 PM, Russell Coker wrote:
On Thu, 20 Aug 2015 11:55:43 AM Chris Murphy wrote:
Question 1: If I apply the NOCOW attribute to a file or directory, how
does that affect my ability to run btrfs scrub?
nodatacow includes nodata
Hi Stephen,
There are a few conflicts for btrfs in linux-next this time. They are
small, but I pushed out the merge commit I'm using here:
git://git.kernel.org/pub/scm/linux/kernel/git/mason/linux-btrfs.git next-merge
-chris
--
To unsubscribe from this list: send the line "unsubscribe linux-bt
tree: git://git.kernel.org/pub/scm/linux/kernel/git/mason/linux-btrfs.git
next-merge
head: 32cf3e1f69b02f4dde97d2e0b949a8c75702e5e6
commit: 32cf3e1f69b02f4dde97d2e0b949a8c75702e5e6 [1/1] Merge branch
'for-linus-4.3' into next
config: i386-randconfig-a0-201533 (attached as .config)
reproduce:
(Resending to list as plaintext (*correctly* this time))
I see. I'll probably make the backup array a raid10 then.
If/when I do see a disk failure on the raid5, are there any specific
steps it would be helpful for me to take to capture the state so you
folks can have a useful bug report?
I p
On Thu, Aug 20, 2015 at 03:09:05PM +0800, Anand Jain wrote:
>
> (thanks for the off-ML emails from the people who helped me
> to understand).
>
> Dave,
>
> looks like you are suggesting something like..
>
> ---
> +_dmerror_mount_options()
> +{
> + _scratch_options mount
> + e
Hi Mark,
Any further comment on the reason why we should mark all nodes/leaves
dirty during a subvolume deletion?
Thanks,
Qu
Qu Wenruo wrote on 2015/08/18 16:03 +0800:
Qu Wenruo wrote on 2015/08/18 09:42 +0800:
Mark Fasheh wrote on 2015/08/17 14:13 -0700:
Hi Qu,
Firstly thanks for the
Hi Chris,
On Thu, 20 Aug 2015 13:39:18 -0400 Chris Mason wrote:
>
> There are a few conflicts for btrfs in linux-next this time. They are
> small, but I pushed out the merge commit I'm using here:
>
> git://git.kernel.org/pub/scm/linux/kernel/git/mason/linux-btrfs.git next-merge
Thanks for tha
Btrfs qgroup reserve codes lacks check for rewrite dirty page, causing
every write, even rewriting a uncommitted dirty page, to reserve space.
But only written data will free the reserved space, causing reserved
space leaking.
The bug exists almost from the beginning of btrfs qgroup codes, but
no
Succeeded in reproducing the bug.
Any missing device will cause btrfs-image to inifinite loop.
It should be easy to fix.
I'll CC you when the patch is out.
Thanks,
Qu
Timothy Normand Miller wrote on 2015/08/18 11:40 -0400:
I've filed a bug report on this:
https://bugzilla.kernel.org/show_bug
Hi Chris,
Would you please consider merging the following fixes for your
integration-4.3 branch?
https://github.com/adam900710/linux.git for_chris_4.3_part1_cleanup
Most of them are harmless cleanups, like removing unused
parameters/judgment, or comment/variant name change.
We have already
This patch includes below fixes in error path:
1. fix memory leaks if realloc() fails
2. add missing call free_history() before return error in scrub_read_file()
Signed-off-by: Byongho Lee
---
btrfs-list.c | 8
cmds-scrub.c | 18 ++
qgroup.c | 8
3 files c
Offline btrfs tools, like btrfs-image, will infinitely loop when there
is missing device.
The reason is, for missing device, it's fd will be set to -1, but before
we reading, we only check the fd validation by checking if it's 0.
So in that case, -1 will pass the validation check, and cause pread
Function read_data_extent() in btrfs-image.c is using manual-and-read
codes.
Replace it with existing read_extent_data() to reduce duplication.
Also, now we can use other mirror to try our best to do the dump, just
like read_tree_block().
Signed-off-by: Qu Wenruo
---
btrfs-image.c | 58
On Thu, 20 Aug 2015 10:09:26 PM Austin S Hemmelgarn wrote:
> > 2: Out of curiosity, why is data checksumming tied to COW?
>
> There's no safe way to sanely handle checksumming without COW, because
> there is no way (at least on current hardware) to ensure that the data
> block and the checksums b
Hi, Byongho Lee
> -Original Message-
> From: linux-btrfs-ow...@vger.kernel.org
> [mailto:linux-btrfs-ow...@vger.kernel.org] On Behalf Of Byongho Lee
> Sent: Friday, August 21, 2015 11:10 AM
> To: linux-btrfs@vger.kernel.org
> Subject: [PATCH] btrfs-progs: fix memory leaks in error path
>
2015-07-13 9:26 GMT+03:00 Dāvis Mosāns :
> also are there some easy way to locate those unreadable sectors and
> rewrite them so hdd relocates them?
>
Only now noticed that scrub does tell it :)
> kernel: BTRFS: i/o error at logical 7358423011328 on dev /dev/sdd,
sector 2879471688, root 3034, ino
Zhao Lei writes:
> Hi, Byongho Lee
>
>> -Original Message-
>> From: linux-btrfs-ow...@vger.kernel.org
>> [mailto:linux-btrfs-ow...@vger.kernel.org] On Behalf Of Byongho Lee
>> Sent: Friday, August 21, 2015 11:10 AM
>> To: linux-btrfs@vger.kernel.org
>> Subject: [PATCH] btrfs-progs: fix me
29 matches
Mail list logo
