Martin,
I agree as of now it's better to refer mkfs. manpage and use it
appropriately.
I will write separate email to fsdevel mailing list.
Thank you,
Regards,
Ankur
-Original Message-
From: Martin Steigerwald [mailto:mar...@lichtvoll.de]
Sent: Monday, December 29, 2014 3:48 PM
To: Anku
Signed-off-by: Gui Hecheng
Reviewed-by: Satoru Takeuchi
---
changelog
v1->v2:
s/\'E\'(EiB)/or \'E\'(EiB)/ as suggested by Satoru, thanks.
v2->v3:
replace confusing format 'K'(KiB) etc. Thanks, David.
---
Documentation/btrfs-filesystem.txt | 5 +++--
On Mon, 2014-12-29 at 17:07 +0100, David Sterba wrote:
> On Mon, Dec 22, 2014 at 03:22:53PM +0800, Gui Hecheng wrote:
> > Signed-off-by: Gui Hecheng
> > Reviewed-by: Satoru Takeuchi
> > ---
> > changelog
> > v1->v2: s/\'E\'(EiB)/or \'E\'(EiB)/ as suggested by Satoru, thanks.
> > ---
> > Docu
Original Message
Subject: Re: 3.16.3: fs/btrfs/delayed-inode.c:1410
btrfs_assert_delayed_root_empty
From: Roman Mamedov
To: Marc MERLIN
Date: 2014年12月29日 04:00
On Sun, 28 Dec 2014 11:26:14 -0800
Marc MERLIN wrote:
Not sure if it's useful to anyone, but there you go. This
Original Message
Subject: Re: [PATCH v2 2/2] btrfs: Enhance btrfs chunk allocation
algorithm to reduce ENOSPC caused by unbalanced data/metadata allocation.
From: David Sterba
To: Qu Wenruo
Date: 2014年12月29日 22:56
On Wed, Dec 24, 2014 at 09:55:14AM +0800, Qu Wenruo wrote:
> On Mon, Dec 29, 2014 at 12:00 PM, sys.syphus wrote:
>> oh, and sorry to bump myself. but is raid10 *ever* more redundant in
>> btrfs-speak than raid1? I currently use raid1 but i know in mdadm
>> speak raid10 means you can lose 2 drives assuming they aren't the
>> "wrong ones", is it safe to say
On Sat, Dec 27, 2014 at 8:12 PM, Phillip Susi wrote:
> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA512
>
> On 12/23/2014 05:09 PM, Chris Murphy wrote:
>> The timer in /sys is a kernel command timer, it's not a device
>> timer even though it's pointed at a block device. You need to
>> change that
On Mon, Dec 29, 2014 at 02:25:14PM -0600, sys.syphus wrote:
> so am I to read that as if btrfs redundancy isn't really functional?
> if i yank a member of my raid 1 out in live "prod" is it going to take
> a dump on my data?
Eh? Where did that conclusion some from? I said nothing at all
about R
On Mon, Dec 29, 2014 at 12:00 PM, sys.syphus wrote:
> oh, and sorry to bump myself. but is raid10 *ever* more redundant in
> btrfs-speak than raid1? I currently use raid1 but i know in mdadm
> speak raid10 means you can lose 2 drives assuming they aren't the
> "wrong ones", is it safe to say with
By asking the question this way, I don't think you understand how
Btrfs development works. But if you check out the git pull for 3.19
you'll see a bunch of patches that pretty much close the feature
parity (no pun intended) gap for raid56 and raid0,1,10. But it is an
rc, and still needs testing, an
so am I to read that as if btrfs redundancy isn't really functional?
if i yank a member of my raid 1 out in live "prod" is it going to take
a dump on my data?
On Mon, Dec 29, 2014 at 1:04 PM, Hugo Mills wrote:
> On Mon, Dec 29, 2014 at 01:00:05PM -0600, sys.syphus wrote:
>> oh, and sorry to bump
On Mon, Dec 29, 2014 at 01:00:05PM -0600, sys.syphus wrote:
> oh, and sorry to bump myself. but is raid10 *ever* more redundant in
> btrfs-speak than raid1? I currently use raid1 but i know in mdadm
> speak raid10 means you can lose 2 drives assuming they aren't the
> "wrong ones", is it safe to sa
oh, and sorry to bump myself. but is raid10 *ever* more redundant in
btrfs-speak than raid1? I currently use raid1 but i know in mdadm
speak raid10 means you can lose 2 drives assuming they aren't the
"wrong ones", is it safe to say with btrfs / raid 10 you can only lose
one no matter what?
--
To u
specifically (P)arity. very specifically n+2. when will raid5 & raid6
be at least as safe to run as raid1 currently is? I don't like the
idea of being 2 bad drives away from total catastrophe.
(and yes i backup, it just wouldn't be fun to go down that route.)
--
To unsubscribe from this list: send
Hi,
there a few more bugfixes that appeared during last week, I did more
testing and am going to release 3.18 tomorrow.
david
--
To unsubscribe from this list: send the line "unsubscribe linux-btrfs" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.
On Mon, Dec 22, 2014 at 07:37:59PM +0900, Satoru Takeuchi wrote:
> --- a/send-utils.h
> +++ b/send-utils.h
> @@ -37,10 +37,10 @@ extern "C" {
> #define BTRFS_COMPAT_SEND_NO_UUID_TREE 1
>
> enum subvol_search_type {
> - subvol_search_by_root_id,
> - subvol_search_by_uuid,
> - subvol_
On Thu, Dec 25, 2014 at 09:16:35AM +0800, Gui Hecheng wrote:
> Now, if exec:
> # btrfs-debug-tree
> it echos:
> : Superblock bytenr is larger than device size
>
> But it is quite misleading, because it is a valid btrfs.
> In this case, we should tell the developer to provide a block d
On Mon, Dec 22, 2014 at 03:22:53PM +0800, Gui Hecheng wrote:
> Signed-off-by: Gui Hecheng
> Reviewed-by: Satoru Takeuchi
> ---
> changelog
> v1->v2: s/\'E\'(EiB)/or \'E\'(EiB)/ as suggested by Satoru, thanks.
> ---
> Documentation/btrfs-filesystem.txt | 4 ++--
> 1 file changed, 2 insertio
On Mon, Dec 29, 2014 at 10:41 AM, Marc MERLIN wrote:
On Mon, Dec 29, 2014 at 10:17:00AM -0500, Chris Mason wrote:
I've hit this recently on my laptop, and haven't yet been able to
recreate it on a machine where I can debug things. The messages are
an error in the log tree replay code, and I
On Mon, Dec 29, 2014 at 10:17:00AM -0500, Chris Mason wrote:
> I've hit this recently on my laptop, and haven't yet been able to
> recreate it on a machine where I can debug things. The messages are
> an error in the log tree replay code, and I don't think they are
> actually related to any corrup
On Sun, Dec 28, 2014 at 4:36 PM, Marc MERLIN wrote:
On Mon, Dec 29, 2014 at 01:00:47AM +0500, Roman Mamedov wrote:
> Will btrfs scrub, even if it takes about 24H to run for me, tell
me
> which FS is affected and if so do I run btrfs repair?
I had this:
https://urldefense.proofpoint.com/v1
On Thu, Dec 25, 2014 at 06:21:41PM +0900, Satoru Takeuchi wrote:
> From: Satoru Takeuchi
> --- a/fs/btrfs/extent_io.c
> +++ b/fs/btrfs/extent_io.c
> @@ -2190,7 +2190,7 @@ void btrfs_free_io_failure_record(struct inode *inode,
> u64 start, u64 end)
>
> next = next_state(state);
>
On Wed, Dec 24, 2014 at 09:55:14AM +0800, Qu Wenruo wrote:
> When btrfs allocate a chunk, it will try to alloc up to 1G for data and
> 256M for metadata, or 10% of all the writeable space if there is enough
> space for the stripe on device.
>
> However, when we run out of space, this allocation ma
On Wed, Dec 24, 2014 at 02:52:04PM +0900, Satoru Takeuchi wrote:
> I once submit the similar patch to btrfs-progs.
> Then Gui Hecheng tell me fixing original code in kernel
> is better.
The kernel header is exported and the authoritative source for the ioctl
definitions, progs usually copy the req
Am Sonntag, 28. Dezember 2014, 17:58:17 schrieb Martin Steigerwald:
> Hi!
>
> After my recent tests with my /home filesystem and the up and downsizing of
> it I get:
>
>
> merkaba:~> LANG=C fstrim -v /home
> /home: 0 B (0 bytes) trimmed
> merkaba:~> LANG=C fstrim -v /
> /: 24.5 GiB (26257555
Am Montag, 29. Dezember 2014, 09:55:13 schrieb Ankur Tank:
> Thank you for reply Anand & Matrin,
>
> Okay I understand the intention now.
> I know it's not the forum to address issues related to mkfs commands
> But I think, options used should be same across the mkfs.XXX commands.
> Another irregu
Am Sonntag, 28. Dezember 2014, 18:04:31 schrieb Patrik Lundquist:
> On 28 December 2014 at 13:03, Martin Steigerwald wrote:
> >
> > BTW, I found that the Oracle blog didn´t work at all for me. I completed
> > a cycle of defrag, sdelete -c and VBoxManage compact, [...] and it
> > apparently did *no
That's by design. More over this is nothing specific to eMMC.
Thanks.
On 29/12/2014 15:15, Ankur Tank wrote:
Hi Anand,
Precondition : Previous filesystem on eMMC was --- ext4
Use case : Now format eMMC to btrfs format, using ---mkfs.btrfs---
mkfs.btrfs denies formatting eMMC telling
Thank you for reply Anand & Matrin,
Okay I understand the intention now.
I know it's not the forum to address issues related to mkfs commands
But I think, options used should be same across the mkfs.XXX commands.
Another irregularity is
mkfs.f2fs takes "-l" to apply label, while
mkfs.ext4 take "-
Am Montag, 29. Dezember 2014, 07:15:11 schrieb Ankur Tank:
> > -Original Message-
> > From: Anand Jain [mailto:anand.j...@oracle.com]
> > Sent: Monday, December 29, 2014 8:21 AM
> > To: Ankur Tank; linux-btrfs@vger.kernel.org
> > Subject: Re: btrfs doesn't format eMMC if previous filesyste
Am Sonntag, 28. Dezember 2014, 21:07:05 schrieb Zygo Blaxell:
> On Sat, Dec 27, 2014 at 08:23:59PM +0100, Martin Steigerwald wrote:
> > My simple test case didn´t trigger it, and I so not have another twice 160
> > GiB available on this SSDs available to try with a copy of my home
> > filesystem. T
Am Sonntag, 28. Dezember 2014, 14:56:21 schrieb Martin Steigerwald:
> Am Sonntag, 28. Dezember 2014, 14:40:32 schrieb Martin Steigerwald:
> > Am Sonntag, 28. Dezember 2014, 14:00:19 schrieb Martin Steigerwald:
> > > Am Samstag, 27. Dezember 2014, 14:55:58 schrieb Martin Steigerwald:
> > > > Summari
Am Sonntag, 28. Dezember 2014, 16:27:41 schrieb Robert White:
> On 12/28/2014 07:42 AM, Martin Steigerwald wrote:
> > Am Sonntag, 28. Dezember 2014, 06:52:41 schrieb Robert White:
> >> On 12/28/2014 04:07 AM, Martin Steigerwald wrote:
> >>> Am Samstag, 27. Dezember 2014, 20:03:09 schrieb Robert Whi
Am Montag, 29. Dezember 2014, 02:08:21 schrieb Duncan:
> Martin Steigerwald posted on Sun, 28 Dec 2014 17:58:17 +0100 as excerpted:
>
> > The fstrim on /home returns immediately. It does not even seem to trim
> > anything. What could be the cause for that?
>
> While I don't know your mapper layou
Original Message
Subject: Read-only filesystem
From: Radosław Kintzi
To:
Date: 2014年12月27日 16:01
Hello
The problem:
Every time I start my browser, file system is remounted in read-only
mode.
The cause:
I believe the problem originates from hard reset I had to do.
The detai
35 matches
Mail list logo
