Duncan posted on Sat, 02 Sep 2017 04:03:06 + as excerpted:
> Austin S. Hemmelgarn posted on Fri, 01 Sep 2017 10:07:47 -0400 as
> excerpted:
>
>> On 2017-09-01 09:54, Qu Wenruo wrote:
>>>
>>> On 2017年09月01日 20:47, Austin S. Hemmelgarn wrote:
>
On 2017-09-01 08:19, Qu Wenruo wrote:
Austin S. Hemmelgarn posted on Fri, 01 Sep 2017 10:07:47 -0400 as
excerpted:
> On 2017-09-01 09:54, Qu Wenruo wrote:
>>
>> On 2017年09月01日 20:47, Austin S. Hemmelgarn wrote:
>>> On 2017-09-01 08:19, Qu Wenruo wrote:
Current kernel (and btrfs-progs also tries to follow kernel chunk
, Qu Wenruo wrote:
On 2017年09月01日 01:27, Goffredo Baroncelli wrote:
Hi All,
I found a bug in mkfs.btrfs, when it is used the option '-r'. It
seems that it is not visible the full disk.
Despite the new bug you found, -r has several existing bugs.
Is this actually a bug though? Every other
, Goffredo Baroncelli wrote:
Hi All,
I found a bug in mkfs.btrfs, when it is used the option '-r'. It
seems that it is not visible the full disk.
Despite the new bug you found, -r has several existing bugs.
Is this actually a bug though? Every other filesystem creation
tool that I know
On 2017-09-01 08:19, Qu Wenruo wrote:
On 2017年09月01日 20:05, Austin S. Hemmelgarn wrote:
On 2017-09-01 07:49, Qu Wenruo wrote:
On 2017年09月01日 19:28, Austin S. Hemmelgarn wrote:
On 2017-08-31 20:13, Qu Wenruo wrote:
On 2017年09月01日 01:27, Goffredo Baroncelli wrote:
Hi All,
I found a bug
On 2017年09月01日 20:05, Austin S. Hemmelgarn wrote:
On 2017-09-01 07:49, Qu Wenruo wrote:
On 2017年09月01日 19:28, Austin S. Hemmelgarn wrote:
On 2017-08-31 20:13, Qu Wenruo wrote:
On 2017年09月01日 01:27, Goffredo Baroncelli wrote:
Hi All,
I found a bug in mkfs.btrfs, when it is used
On 2017-09-01 07:49, Qu Wenruo wrote:
On 2017年09月01日 19:28, Austin S. Hemmelgarn wrote:
On 2017-08-31 20:13, Qu Wenruo wrote:
On 2017年09月01日 01:27, Goffredo Baroncelli wrote:
Hi All,
I found a bug in mkfs.btrfs, when it is used the option '-r'. It
seems that it is not visible the full
On 2017年09月01日 19:28, Austin S. Hemmelgarn wrote:
On 2017-08-31 20:13, Qu Wenruo wrote:
On 2017年09月01日 01:27, Goffredo Baroncelli wrote:
Hi All,
I found a bug in mkfs.btrfs, when it is used the option '-r'. It
seems that it is not visible the full disk.
Despite the new bug you found
On 2017年09月01日 19:28, Austin S. Hemmelgarn wrote:
On 2017-08-31 20:13, Qu Wenruo wrote:
On 2017年09月01日 01:27, Goffredo Baroncelli wrote:
Hi All,
I found a bug in mkfs.btrfs, when it is used the option '-r'. It
seems that it is not visible the full disk.
Despite the new bug you found
On 2017-08-31 16:29, Goffredo Baroncelli wrote:
On 2017-08-31 20:49, Austin S. Hemmelgarn wrote:
On 2017-08-31 13:27, Goffredo Baroncelli wrote:
Hi All,
I found a bug in mkfs.btrfs, when it is used the option '-r'. It
seems that it is not visible the full disk.
$ uname -a Linux venice.bhome
On 2017-08-31 20:13, Qu Wenruo wrote:
On 2017年09月01日 01:27, Goffredo Baroncelli wrote:
Hi All,
I found a bug in mkfs.btrfs, when it is used the option '-r'. It seems
that it is not visible the full disk.
Despite the new bug you found, -r has several existing bugs.
Is this actually a bug
On 2017年09月01日 01:27, Goffredo Baroncelli wrote:
Hi All,
I found a bug in mkfs.btrfs, when it is used the option '-r'. It seems that it
is not visible the full disk.
Despite the new bug you found, -r has several existing bugs.
For example it will create dev extent starting from physical
On 2017-08-31 20:49, Austin S. Hemmelgarn wrote:
> On 2017-08-31 13:27, Goffredo Baroncelli wrote:
>> Hi All,
>>
>>
>> I found a bug in mkfs.btrfs, when it is used the option '-r'. It
>> seems that it is not visible the full disk.
>>
>> $ uname -a
On 2017-08-31 13:27, Goffredo Baroncelli wrote:
Hi All,
I found a bug in mkfs.btrfs, when it is used the option '-r'. It seems that it
is not visible the full disk.
$ uname -a
Linux venice.bhome 4.12.8 #268 SMP Thu Aug 17 09:03:26 CEST 2017 x86_64
GNU/Linux
$ btrfs --version
btrfs-progs
Hi All,
I found a bug in mkfs.btrfs, when it is used the option '-r'. It seems that it
is not visible the full disk.
$ uname -a
Linux venice.bhome 4.12.8 #268 SMP Thu Aug 17 09:03:26 CEST 2017 x86_64
GNU/Linux
$ btrfs --version
btrfs-progs v4.12
--- First try without '-r' (/dev/sda is about
when i create raid5 in btrfs ,command like this:
./mkfs.btrfs -d raid5 /dev/sdb /dev/sdc /dev/sdd /dev/sde /dev/sdf
/dev/sdg /dev/sdh /dev/sdi /dev/sdj /dev/sdk /dev/sdl /dev/sdm -f
WARNING! - Btrfs v0.20-rc1-358-g194aa4a-dirty IS EXPERIMENTAL
WARNING! - see http://btrfs.wiki.kernel.org before
On Thu, Oct 24, 2013 at 10:22:28PM +0800, lilofile wrote:
Oct 24 21:25:36 host1 kernel: [ 3000.809563] [81315c14]
blkdev_issue_discard+0x1b4/0x1c0
There's an discard/TRIM operation being done on all of the devices,
current progs do not report that and it's really confusing. Fixed in
felixbla...@gmail.com, kreij...@inwind.it, Hugo Mills
hugo-l...@carfax.org.uk, linux-btrfs@vger.kernel.org, Linux Kernel
linux-ker...@vger.kernel.org
Subject: Re: LOOP_GET_STATUS(64) truncates pathnames to 64 chars (was Re:
Bug in mkfs.btrfs?!)
Mail-Followup-To: Chris Samuel ch...@csamuel.org
On 02/11/2011 08:23 PM, Felix Blanke wrote:
What do you mean with configured?
I'm using loop devices with loop aes, and I've looked into /sys for a device
which is actually in use.
Ehm. It is really Loop-AES?
Then ask author to backport it there, Loop-AES is not mainline code.
He usually
Yeah, for me its loop-aes.
Ah ok, didn't knew that it replaces that whole loop thing :)
Felix
On Feb 11, 2011 8:32 PM, Milan Broz mb...@redhat.com wrote:
On 02/11/2011 08:23 PM, Felix Blanke wrote:
What do you mean with configured?
I'm using loop devices with loop aes, and I've looked into
On Tue, Jan 25, 2011 at 11:15:11AM +1100, Chris Samuel wrote:
/*
* CC'd to linux-kernel in case they have any feedback on this.
*
* Long thread, trying to work out why mkfs.btrfs failed to
* make a filesystem on an encrypted loopback mount called
* /dev/loop2. Cause turned out to be
Hi,
attached is the answer from Jari Ruusu, (one of?!) the main developer of
loop-aes. It
seems that checking if a loop device is mounted following the link isn't the
best
idea :)
I'll have time to look deeper into his example about the 14.02. I'll then try
to fix
that issue in mkfs.btrfs. If
On 24. January 2011 - 13:13, Hugo Mills wrote:
Date: Mon, 24 Jan 2011 13:13:41 +
From: Hugo Mills hugo-l...@carfax.org.uk
To: Felix Blanke felixbla...@gmail.com
Cc: kreij...@inwind.it, Hugo Mills hugo-l...@carfax.org.uk,
linux-btrfs@vger.kernel.org
Subject: Re: Bug in mkfs.btrfs?!
Mail
On Mon, Jan 24, 2011 at 02:29:36PM +, Hugo Mills wrote:
If, instead, the initial losetup call tracked the symlinks back to
the original device node (i.e. something like /dev/sdb3, or
/dev/mapper/ruthven-btest in my example), then the name that's
stored in the kernel would be shorter,
On Mon, Jan 24, 2011 at 02:53:05PM +0100, Felix Blanke wrote:
On 24. January 2011 - 13:13, Hugo Mills wrote:
On Mon, Jan 24, 2011 at 02:01:04PM +0100, Felix Blanke wrote:
Hi,
you were talking about the LOOP_GET_STATUS function. I'm not quite sure
where does it
came
On Mon, Jan 24, 2011 at 02:29:36PM +, Hugo Mills wrote:
If, instead, the initial losetup call tracked the symlinks back to
the original device node (i.e. something like /dev/sdb3, or
/dev/mapper/ruthven-btest in my example), then the name that's
stored in the kernel would be
:14 +0100
From: Felix Blanke felixbla...@gmail.com
To: Hugo Mills hugo-l...@carfax.org.uk
Cc: kreij...@inwind.it, linux-btrfs@vger.kernel.org
Subject: Re: Bug in mkfs.btrfs?!
On Mon, Jan 24, 2011 at 02:29:36PM +, Hugo Mills wrote:
If, instead, the initial losetup call tracked
if there are any gentoo-patches applied during the build.
Felix
On 24. January 2011 - 17:00, Hugo Mills wrote:
Date: Mon, 24 Jan 2011 17:00:24 +
From: Hugo Mills hugo-l...@carfax.org.uk
To: Felix Blanke felixbla...@gmail.com
Cc: linux-btrfs@vger.kernel.org
Subject: Re: Bug in mkfs.btrfs?!
Mail
Subject: Re: Bug in mkfs.btrfs?!
Mail-Followup-To: Hugo Mills hugo-l...@carfax.org.uk, Felix Blanke
felixbla...@gmail.com, linux-btrfs@vger.kernel.org
On Mon, Jan 24, 2011 at 05:52:58PM +0100, Felix Blanke wrote:
util-linux-2.18-r1 and still no symlink following.
I'll ask
Hi, Felix,
On Sat, Jan 22, 2011 at 04:56:12PM +0100, Felix Blanke wrote:
It was a simple:
mkfs.btrfs -L backup -d single /dev/loop2
But it also happens without the options, like:
mkfs.btrfs /dev/loop2
/dev/loop2 is a loop device, which is aes encrypted. The output of losetup
On 01/23/2011 07:18 PM, Hugo Mills wrote:
Hi, Felix,
On Sat, Jan 22, 2011 at 04:56:12PM +0100, Felix Blanke wrote:
It was a simple:
mkfs.btrfs -L backup -d single /dev/loop2
But it also happens without the options, like:
mkfs.btrfs /dev/loop2
/dev/loop2 is a loop device, which is
: Bug in mkfs.btrfs?!
On 01/23/2011 07:18 PM, Hugo Mills wrote:
Hi, Felix,
On Sat, Jan 22, 2011 at 04:56:12PM +0100, Felix Blanke wrote:
It was a simple:
mkfs.btrfs -L backup -d single /dev/loop2
But it also happens without the options, like:
mkfs.btrfs /dev/loop2
/dev
On Sun, Jan 23, 2011 at 11:02:16PM +0100, Goffredo Baroncelli wrote:
On 01/23/2011 07:18 PM, Hugo Mills wrote:
Hi, Felix,
On Sat, Jan 22, 2011 at 04:56:12PM +0100, Felix Blanke wrote:
It was a simple:
mkfs.btrfs -L backup -d single /dev/loop2
But it also happens without the
felixbla...@gmail.com, linux-btrfs@vger.kernel.org
Subject: Re: Bug in mkfs.btrfs?!
Mail-Followup-To: Hugo Mills h...@carfax.org.uk, kreij...@inwind.it, Hugo
Mills hugo-l...@carfax.org.uk, Felix Blanke felixbla...@gmail.com,
linux-btrfs@vger.kernel.org
On Sun, Jan 23, 2011 at 11:02:16PM +0100
Hi,
I wanted to create a new btrfs fs for my backups.
When trying to mkfs.btrfs for that device, I'm getting
error checking /dev/loop2 mount status
With strace I see where the problem is:
lstat(/dev/disk/by-id/ata-INTEL_SSDSA2M160G2GC_CVPO939201JX160AGN-par,
0x7fffa30b3cf0) = -1 ENOENT (No
From: Felix Blanke felixbla...@gmail.com
To: linux-btrfs@vger.kernel.org
Subject: Bug in mkfs.btrfs?!
Hi,
I wanted to create a new btrfs fs for my backups.
When trying to mkfs.btrfs for that device, I'm getting
error checking /dev/loop2 mount status
With strace I see where
36 matches
Mail list logo
