On 2/24/21 9:13 PM, Qu Wenruo wrote:
> Now this makes way more sense,
Sorry for the earlier mistake.
> as your previous comment on
> _btrfs_forget_or_module_reload is completely correct.
>
> _btrfs_forget_or_module_reload will really forget all devices, while
> what we really want is just exclu
On 2/24/21 7:56 PM, Qu Wenruo wrote:
>
>
> On 2021/2/25 上午9:46, Eric Sandeen wrote:
>> On 2/24/21 7:16 PM, Anand Jain wrote:
>>> On 25/02/2021 05:39, Eric Sandeen wrote:
>>>> On 2/24/21 10:12 AM, Eric Sandeen wrote:
>>>>> Last week I was cu
On 2/24/21 7:16 PM, Anand Jain wrote:
> On 25/02/2021 05:39, Eric Sandeen wrote:
>> On 2/24/21 10:12 AM, Eric Sandeen wrote:
>>> Last week I was curious to just see how btrfs is faring with RAID5 in
>>> xfstests, so I set it up for a quick run with devices configure
On 2/24/21 10:12 AM, Eric Sandeen wrote:
> Last week I was curious to just see how btrfs is faring with RAID5 in
> xfstests, so I set it up for a quick run with devices configured as:
Whoops this was supposed to cc: fstests, not fsdevel, sorry.
-Eric
> TEST_DEV=/dev/sdb1 # <---
Last week I was curious to just see how btrfs is faring with RAID5 in
xfstests, so I set it up for a quick run with devices configured as:
TEST_DEV=/dev/sdb1 # <--- this was a 3-disk "-d raid5" filesystem
SCRATCH_DEV_POOL="/dev/sdb2 /dev/sdb3 /dev/sdb4 /dev/sdb5 /dev/sdb6"
and fired off ./check -
I lifted the btrfs label get/set ioctls to the vfs some time ago, but
never followed up to use those common definitions directly in btrfs.
This patch does that.
Signed-off-by: Eric Sandeen
---
diff --git a/fs/btrfs/ioctl.c b/fs/btrfs/ioctl.c
index 56ae2f659b6d..65aeb418aa9d 100644
--- a/fs
On 10/1/18 9:48 AM, Qu Wenruo wrote:
>
>
> On 2018/10/1 下午10:32, Joshi wrote:
>> I was wondering about the cross-fs copy through copy_file_range.
>
> The term "cross-fs" looks pretty confusing.
>
> If you mean "cross-subvolume", then it should work without problem in btrfs.
>
> If you mean ref
On 8/20/18 7:49 PM, Dave Chinner wrote:
> Upon successful completion of this ioctl, the number of
> bytes successfully deduplicated is returned in bytes_deduped
> and a status code for the deduplication operation is
> returned in status. If even a single byte in the rang
riate ioctl" can be caught in the
common case.
Signed-off-by: Eric Sandeen
---
Now with new and improved sequential V4 versioning!
This passes on btrfs, _notruns on xfs/ext4 of yore, and passes
on xfs w/ my online label patchset (as long as xfs_io has the new
capability)
V2: Add a max la
On 5/15/18 7:51 PM, Dave Chinner wrote:
On Tue, May 15, 2018 at 10:22:37AM -0500, Eric Sandeen wrote:
This tests the online label ioctl that btrfs has, which has been
recently proposed for XFS.
To run, it requires an updated xfs_io with the label command and a
filesystem that supports it
A
riate ioctl" can be caught in the
common case.
Signed-off-by: Eric Sandeen
---
(urgh send as proper new thread, sorry)
This passes on btrfs, _notruns on xfs/ext4 of yore, and passes
on xfs w/ my online label patchset (as long as xfs_io has the new
capability)
V2: Add a max label len
On 5/14/18 6:11 PM, Dave Chinner wrote:
> On Mon, May 14, 2018 at 12:09:16PM -0500, Eric Sandeen wrote:
>> This tests the online label ioctl that btrfs has, which has been
>> recently proposed for XFS.
>>
>> To run, it requires an updated xfs_io with the label comma
riate ioctl" can be caught in the
common case.
Signed-off-by: Eric Sandeen
---
(urgh send as proper new thread, sorry)
This passes on btrfs, _notruns on xfs/ext4 of yore, and passes
on xfs w/ my online label patchset (as long as xfs_io has the new
capability)
V2: Add a max label length help
riate ioctl" can be caught in the
common case.
Signed-off-by: Eric Sandeen
---
This passes on btrfs, _notruns on xfs/ext4 of yore, and passes
on xfs w/ my online label patchset (as long as xfs_io has the new
capability)
V2: Add a max label length helper
Set the proper btrfs max label
On 5/11/18 9:32 AM, Chris Mason wrote:
> On 11 May 2018, at 10:10, David Sterba wrote:
>
>> On Thu, May 10, 2018 at 08:16:09PM +0100, Al Viro wrote:
>>> On Thu, May 10, 2018 at 01:13:57PM -0500, Eric Sandeen wrote:
>>>> Move the btrfs label ioctls up to the vf
Move the btrfs label ioctls up to the vfs for general use.
This retains 256 chars as the maximum size through the interface, which
is the btrfs limit and AFAIK exceeds any other filesystem's maximum
label size.
Signed-off-by: Eric Sandeen
Reviewed-by: Andreas Dilger
Reviewed-by: David S
On 5/10/18 12:29 PM, Eric Sandeen wrote:
> This documents the proposed new vfs-level ioctls which can
> get or set a mounted filesytem's label.
>
> Signed-off-by: Eric Sandeen
> ---
>
> V2: make primary file ioctl_getfslabel, link ioctl_setfslabel to it
>
This documents the proposed new vfs-level ioctls which can
get or set a mounted filesytem's label.
Signed-off-by: Eric Sandeen
---
V2: make primary file ioctl_getfslabel, link ioctl_setfslabel to it
note that getfslabel requires CAP_SYS_ADMIN
diff --git a/man2/ioctl_getfslabel.2 b
On 5/9/18 12:35 PM, Randy Dunlap wrote:
> On 05/09/2018 09:01 AM, Eric Sandeen wrote:
>> Move the btrfs label ioctls up to the vfs for general use.
>>
>> This retains 256 chars as the maximum size through the interface, which
>> is the btrfs limit and AFAIK exceeds any
On 5/9/18 10:49 AM, Eryu Guan wrote:
> On Mon, Apr 30, 2018 at 04:43:18PM -0500, Eric Sandeen wrote:
>> This tests the online label ioctl that btrfs has, which has been
>> recently proposed for XFS.
>>
>> To run, it requires an updated xfs_io with the label comma
This documents the proposed new vfs-level ioctls which can
get or set a mounted filesytem's label.
Signed-off-by: Eric Sandeen
---
btrfs folks, please verify that this accurately describes your
current behavior, thanks.
diff --git a/man2/ioctl_fslabel.2 b/man2/ioctl_fslabel.2
new file
Move the btrfs label ioctls up to the vfs for general use.
This retains 256 chars as the maximum size through the interface, which
is the btrfs limit and AFAIK exceeds any other filesystem's maximum
label size.
Signed-off-by: Eric Sandeen
---
Let the bikeshedding on the exact ioctl name
I'm planning to add online label set/get support to xfs, and to do so
I plan to re-use the existing btrfs ioctls, BTRFS_IOC_[SG]ET_FSLABEL
We're still working out minor details on the xfs side, but I'd like to
start the conversation regarding the new more generic interface ASAP,
so here goes - pat
riate ioctl" can be caught in the
common case.
Signed-off-by: Eric Sandeen
---
this passes on btrfs, _notruns on xfs/ext4 of yore, and passes
on xfs w/ my online label patchset (as long as xfs_io has the new
capability)
diff --git a/common/rc b/common/rc
index 9ffab7f..c53a721 100644
--- a
On 9/19/17 10:35 AM, Timofey Titovets wrote:
> Stupid question:
> Does btrfs use crc32 for error correction?
> If no, why?
>
> (AFAIK if using CRC that possible to fix 1 bit flip)
>
> P.S. I try check that (i create image, create text file, flip bit, try
> read and btrfs show IO-error)
>
> Thank
On 8/24/17 12:01 PM, David Sterba wrote:
> On Wed, Aug 16, 2017 at 08:17:00AM +0800, Qu Wenruo wrote:
>>
>>
>> On 2017年08月16日 02:11, Eric Sandeen wrote:
>>> The mktables binary needs to be build with the host
>>> compiler at built time, not the target compile
On 8/15/17 7:17 PM, Qu Wenruo wrote:
>
>
> On 2017年08月16日 02:11, Eric Sandeen wrote:
>> The mktables binary needs to be build with the host
>> compiler at built time, not the target compiler, because
>> it runs at build time to generate the raid tables.
>>
On 8/15/17 12:28 PM, Eric Sandeen wrote:
> I guess it's harder to do in btrfs-progs since it's not using autotools...
Eh, I don't know why I thought that was still true :) patch sent.
-Eric
--
To unsubscribe from this list: send the line "unsubscribe linux-btrfs"
The mktables binary needs to be build with the host
compiler at built time, not the target compiler, because
it runs at build time to generate the raid tables.
Copy auto-fu from xfsprogs and modify Makefile to
accomodate this.
Reported-by: Hallo32
Signed-off-by: Eric Sandeen
---
diff --git a
On 8/15/17 7:48 AM, David Sterba wrote:
> On Tue, Aug 15, 2017 at 02:44:07PM +0200, Hallo32 wrote:
...
How the kernel deals with this kind of problem ?
Looking at the source of btrfs Makefile, it is more simple to replace
mktables: kernel-lib/mktables.c
@echo
On 4/7/17 10:42 AM, Darrick J. Wong wrote:
> On Fri, Apr 07, 2017 at 01:02:58PM +0800, Eryu Guan wrote:
>> On Thu, Apr 06, 2017 at 11:28:01AM -0500, Eric Sandeen wrote:
>>> On 4/6/17 11:26 AM, Theodore Ts'o wrote:
>>>> On Wed, Apr 05, 2017 at 10:35:26AM +0800
On 4/6/17 11:26 AM, Theodore Ts'o wrote:
> On Wed, Apr 05, 2017 at 10:35:26AM +0800, Eryu Guan wrote:
>>
>> Test fails with ext3/2 when driving with ext4 driver, fiemap changed
>> after umount/mount cycle, then changed back to original result after
>> sleeping some time. An ext4 bug? (cc'ed linux-e
On 3/17/17 11:25 AM, Austin S. Hemmelgarn wrote:
> I'm currently working on a plugin for colllectd [1] to track per-device
> per-filesystem error rates for BTRFS volumes. Overall, this is actually
> going quite well (I've got most of the secondary logic like matching
> filesystems to watch and
On 1/10/17 9:00 PM, Qu Wenruo wrote:
>
>
> At 01/11/2017 10:53 AM, Eric Sandeen wrote:
>> On 1/10/17 8:45 PM, Qu Wenruo wrote:
>>>
>>>
>>> At 01/11/2017 10:40 AM, Eric Sandeen wrote:
>>
>> ...
>>
>>>> What version
On 1/10/17 8:45 PM, Qu Wenruo wrote:
>
>
> At 01/11/2017 10:40 AM, Eric Sandeen wrote:
...
>> What version of kernel and xfsprogs were you testing, and what was the
>> segfault?
>
> Kernel is mainline v4.10-rc1.
> No debuginfo installed, so no backtrace, but
On 1/10/17 8:08 PM, Qu Wenruo wrote:
> Hi, Andreas and Eryu,
>
> I found test case generic/389 fails on btrfs and ext4, and it fails with
> xfs_io segfault.
Details, please?
Works ok here:
# ./check generic/389
FSTYP -- ext4
PLATFORM -- Linux/x86_64 bp-05 4.9.0-rc1+
MKFS_OPTIONS
On 1/8/17 8:11 PM, Qu Wenruo wrote:
>
>
> At 01/08/2017 09:16 PM, Goldwyn Rodrigues wrote:
>>
>> 1. Motivation
>> While fixing user space tools for btrfs-progs, I found a couple of bugs
>> which are already solved in kernel space but were not ported to user
>> space. User space is a little ignore
On 10/27/16 9:54 PM, Eric Sandeen wrote:
> On 10/13/16 12:36 PM, Eric Sandeen wrote:
>> This was reported when docker failed to build against
>> btrfs-progs v4.8.1.
>>
>> It includes ioctl.h which now calls BUILD_ASSERT(), which
>> is defined in kerncompat
On 10/13/16 12:36 PM, Eric Sandeen wrote:
> This was reported when docker failed to build against
> btrfs-progs v4.8.1.
>
> It includes ioctl.h which now calls BUILD_ASSERT(), which
> is defined in kerncompat.h, which was not included in the
> ioctl.h header file.
Ping?
-Eric
roceed.
If run against an old kernel, worst case scenario is that
no shared extents will be reported via the du command.
Signed-off-by: Eric Sandeen
---
you can take it or leave it, but I had this locally
anyway, so if it's helpful here you go :)
diff --git a/cmds-fi-du.c b/cmds-fi-du.c
in
On 10/14/16 10:49 AM, David Sterba wrote:
> On Thu, Oct 13, 2016 at 03:25:57PM +0800, Qu Wenruo wrote:
>> At 10/13/2016 01:26 AM, David Sterba wrote:
>>> On Wed, Oct 12, 2016 at 10:01:27PM +0800, Qu Wenruo wrote:
On 10/12/2016 09:58 PM, Abhay Sachan wrote:
> Hi,
> I tried bui
This was reported when docker failed to build against
btrfs-progs v4.8.1.
It includes ioctl.h which now calls BUILD_ASSERT(), which
is defined in kerncompat.h, which was not included in the
ioctl.h header file.
Signed-off-by: Eric Sandeen
---
diff --git a/ioctl.h b/ioctl.h
index a7235c0
On 10/12/16 9:45 AM, Abhay Sachan wrote:
> Hi Qu,
> I am running latest 4.8.1, which I compiled on the machine itself.
You likely still have the fiemap.h from Centos' kernel-headers
rpm, which is from an older kernel and does not define it.
-Eric
> Linux vm88 4.8.1 #1 SMP Thu Oct 13 10:33:08 IS
On 9/13/16 4:44 PM, Eric Sandeen wrote:
> on ppc64, 4.7-rc kernel, git btrfs-progs, v4.7.2:
>
> # truncate --size=500m testfile
> # ./mkfs.btrfs testfile
> # mkdir -p mnt
> # mount -o loop testfile mnt
Same failure on aarch64 if that makes it any more interesting. ;)
# moun
on ppc64, 4.7-rc kernel, git btrfs-progs, v4.7.2:
# truncate --size=500m testfile
# ./mkfs.btrfs testfile
# mkdir -p mnt
# mount -o loop testfile mnt
btrfs-progs v4.7.2
See http://btrfs.wiki.kernel.org for more information.
Label: (null)
UUID: c531b759-a491-4c9f-a954-4
On 9/1/16 7:44 AM, David Sterba wrote:
> Signed-off-by: David Sterba
Reviewed-by: Eric Sandeen
> ---
> fs/btrfs/sysfs.c | 9 +
> 1 file changed, 9 insertions(+)
>
> diff --git a/fs/btrfs/sysfs.c b/fs/btrfs/sysfs.c
> index 804bd1c42e47..31f09564e170 100644
>
On 8/31/16 2:08 PM, David Sterba wrote:
> On Wed, Aug 31, 2016 at 10:13:49AM -0500, Eric Sandeen wrote:
>> A /sys/kernel/debug/btrfs/test file was added nearly
>> two and a half years ago, but it serves no purpose;
>
> It does. Introduced in 1bae30982bc86ab66d61ccb6
: Eric Sandeen
---
diff --git a/fs/btrfs/sysfs.c b/fs/btrfs/sysfs.c
index 4879656..fb84685 100644
--- a/fs/btrfs/sysfs.c
+++ b/fs/btrfs/sysfs.c
@@ -834,7 +834,7 @@ static int btrfs_init_debugfs(void)
if (!btrfs_debugfs_root_dentry)
return -ENOMEM;
- debugfs_create_u64
world-writable;
it is the only such file under /sys/kernel/debug, and without
knowledge of its purpose, some users were alarmed by this.
Another option would be to change the perms, but given that
there is no point to it as far as I can tell, it seems best
to simply remove it.
Signed-off-by: Eric
On 7/6/16 8:35 AM, Holger Hoffstätte wrote:
> On 07/06/16 14:25, Wang Shilong wrote:
...
>> After patch, it will look like:
>>Total Exclusive Set shared Filename
>> skipping not btrfs dir/file: boot
>> skipping not btrfs dir/file: dev
>> skipping not btrfs dir/file: proc
>> skipping not b
On 6/23/16 8:49 PM, Steven Haigh wrote:
> I've tried to build the new tools for CentOS 6 / Scientific Linux 6 / RHEL 6
> etc.
>
> During the build process, I see:
> cmds-fi-du.c: In function 'du_calc_file_space':
> cmds-fi-du.c:330: error: 'FIEMAP_EXTENT_SHARED' undeclared (first use in this
> f
On 5/9/16 8:16 PM, Qu Wenruo wrote:
> Hi David, Mark,
>
> In the recent test for new btrfs-convert backward compatibility, I
> found that cmds-fi-du.c uses FIEMAP_EXTENT_SHARED bits, which is not
> present in kernel of old distributions like RHEL6 (Sorry, didn't test
> on openSUSE equivalent).
Th
On 12/17/15 8:01 PM, Christoph Anton Mitterer wrote:
> On Fri, 2015-12-18 at 09:29 +0800, Qu Wenruo wrote:
>> Given that nothing in the documentation implies that the block
>>> device itself
>>> must remain unchanged on a read-only mount, I don't see any problem
>>> which
>>> needs fixing. MS_RD
On 12/16/15 7:41 PM, Qu Wenruo wrote:
> Hi,
>
> In a recent btrfs patch, it is going to add a mount option to disable
> log replay for btrfs, just like "norecovery" for ext4/xfs.
>
> But in the discussion on the mount option name and use case, it seems
> better to have an unified and fs indepen
On 12/11/15 4:21 PM, Christoph Anton Mitterer wrote:
>> Note that Btrfs is
>> > not unique, XFS v5 does a very similar thing with volume UUID as
>> > well,
>> > and resulted in this change:
>> > http://oss.sgi.com/pipermail/xfs/2015-April/041267.html
> Do you mean that xfs may suffer from the same
On 12/7/15 2:54 PM, Christoph Anton Mitterer wrote:
...
> 2) a section that describes "ro" in btrfs-mount(5) which describes that
> normal "ro" alone may cause changes on the device and which then refers
> to hard-ro and/or the list of options (currently nologreplay) which are
> required right n
On 12/7/15 10:52 AM, Chandan Rajendra wrote:
> On Monday 07 Dec 2015 10:27:05 Eric Sandeen wrote:
>> On 12/7/15 12:06 AM, Qu Wenruo wrote:
>>> Introduce a new mount option "nologreplay" to co-operate with "ro" mount
>>> option to get real re
On 12/7/15 12:06 AM, Qu Wenruo wrote:
> Introduce a new mount option "nologreplay" to co-operate with "ro" mount
> option to get real readonly mount, like "norecovery" in ext* and xfs.
>
> Since the new parse_options() need to check new flags at remount time,
> so add a new parameter for parse_opt
On 12/2/15 11:48 AM, Austin S Hemmelgarn wrote:
> On a side note, do either XFS or ext4 support removing the norecovery
> option from the mount flags through mount -o remount? Even if they
> don't, that might be a nice feature to have in BTRFS if we can safely
> support it.
It's not remountable
On 12/2/15 3:23 AM, Qu Wenruo wrote:
>
>
> Qu Wenruo wrote on 2015/12/02 17:06 +0800:
>>
>>
>> Russell Coker wrote on 2015/12/02 17:25 +1100:
>>> On Wed, 2 Dec 2015 06:05:09 AM Eric Sandeen wrote:
>>>> yes, xfs does; we have "-o noreco
On 12/1/15 1:00 PM, Chris Mason wrote:
> On Mon, Nov 30, 2015 at 05:06:00PM +, Hugo Mills wrote:
>> On Mon, Nov 30, 2015 at 11:48:01AM -0500, Chris Mason wrote:
>>> On Sat, Nov 28, 2015 at 01:46:34PM +, Hugo Mills wrote:
We've just had someone on IRC with a problem mounting their FS
On 11/24/15 2:38 PM, Austin S Hemmelgarn wrote:
> if the system was
> shut down cleanly, you're fine barring software bugs, but if it
> crashed, you should be running a check on the FS.
Um, no...
The *entire point* of having a journaling filesystem is that after a
crash or power loss, a journal
On 11/24/15 12:56 AM, Duncan wrote:
> Duncan posted on Tue, 24 Nov 2015 06:46:18 + as excerpted:
>
>> That wouldn't be entirely uncommon, because as Eric mentions, btrfs
>> check is intended to be thorough, where the kernel mount-time check is
>> intended to be fast.
>>
>> But of course, as Er
On 11/23/15 10:35 PM, Duncan wrote:
> Christoph Anton Mitterer posted on Tue, 24 Nov 2015 05:02:34 +0100 as
> excerpted:
>
>> Hey.
>>
>> Short question since that came up on debian-devel.
>>
>> Now that btrfs check get's more and more useful, are the developers
>> going to recommend running it per
On 10/21/15 9:49 AM, Anand Jain wrote:
>
>
> On 10/21/2015 10:41 PM, Eric Sandeen wrote:
>> On 10/21/15 4:09 AM, Qu Wenruo wrote:
>>>> +static int get_kernel_code()
>>>> +{
>>>> +int ret;
>>>> +struct utsname utsbuf
On 10/21/15 4:09 AM, Qu Wenruo wrote:
>> +static int get_kernel_code()
>> +{
>> +int ret;
>> +struct utsname utsbuf;
>> +char *version;
>> +
>> +ret = uname(&utsbuf);
>> +if (ret)
>> +return -ret;
>> +
>> +version = strtok(utsbuf.release, "-");
>> +
>> +return ve
On 10/11/15 11:37 PM, Wang, Zhiye wrote:
> Hello everyone,
>
> After googled a bit, I got information that btrfs supports FIEMAP (as "cp"
> needs it), but it's not valid for "write" operation.
cp should not be using fiemap any more. It was for a while, until they
realized that copying based on
On 9/30/15 4:56 PM, Dave Chinner wrote:
> On Wed, Sep 30, 2015 at 10:57:45PM +0300, Roman Lebedev wrote:
>> As per overlayfs documentation, any activity on a merged directory
>> for a application that is doing such activity should work exactly
>> as if that would be a normal, non overlayfs-merged
On 8/13/15 3:47 AM, Liu Bo wrote:
> Btrfs has a problem when defraging a file which has a large fragment'ed range,
> it'd leave the tail extent as a seperate extent instead of merging it with
> previous extents.
>
> This makes generic/018 recognize the above regression.
Sorry for the late review,
> On Jun 21, 2015, at 1:11 PM, Swâmi Petaramesh wrote:
>
> Le dimanche 21 juin 2015 22:31:21 Roman Mamedov a écrit :
>>
>> Yes the "nossd" option (written literally like that) does in fact exist.
>> It would have taken you less time to try if it works, than to write this
>> long-winded message.
On 4/20/15 12:33 AM, xuw2...@gmail.com wrote:
> From: George Wang
>
> PPC64 arch use such following IOC values "
> \#define _IOC_NONE 1U
> \#define _IOC_READ 2U
> \#define _IOC_WRITE 4U
> " comparing to the default IOC values "
> \#define _IOC_NONE 0U
> \#define _IOC_READ
On 3/26/15 10:34 PM, Eryu Guan wrote:
> Just FYI.
>
> I think generic/204 is a test case issue, _filter_mkfs failed to print
> isize and dbsize for btrfs and test failed because of divide by zero
> error.
>
> --- /dev/fd/632015-03-25 12:17:05.987107715 -0400
> +++ results/generic/204.out
hings back
to something semi-sane.
Signed-off-by: Eric Sandeen
---
V2: truncate seqres.full on first write, thanks Eryu!
diff --git a/common/filter b/common/filter
index 71ef2e2..05dbae6 100644
--- a/common/filter
+++ b/common/filter
@@ -137,10 +137,6 @@ _filter_mkfs()
case $FSTYP in
x
On 3/26/15 12:25 PM, Filipe David Manana wrote:
> On Thu, Mar 26, 2015 at 5:11 PM, Eric Sandeen wrote:
>> On 3/26/15 9:48 AM, Chris Mason wrote:
>>> On Thu, Mar 26, 2015 at 10:11 AM, Eric Sandeen wrote:
>>
>> ...
>>
>>>>>> 9c4f61f btrfs: sim
hings back
to something semi-sane.
Signed-off-by: Eric Sandeen
---
diff --git a/common/filter b/common/filter
index 71ef2e2..05dbae6 100644
--- a/common/filter
+++ b/common/filter
@@ -137,10 +137,6 @@ _filter_mkfs()
case $FSTYP in
xfs)
;;
- btrfs)
- sed -e &qu
On 3/26/15 9:48 AM, Chris Mason wrote:
> On Thu, Mar 26, 2015 at 10:11 AM, Eric Sandeen wrote:
...
>>>> 9c4f61f btrfs: simplify insert_orphan_item
>>>>
>>>> made the whole path alloc/free go away.
>>
>> so I think there's no need for
On 3/26/15 5:23 AM, Filipe David Manana wrote:
> On Thu, Mar 26, 2015 at 3:24 AM, Eric Sandeen wrote:
>> Looks like "btrfs: fix leak of path in btrfs_find_item" got sent
>> to stable trees, but in my testing, it causes deadlocks on mount:
>>
>> [23379.35924
Looks like "btrfs: fix leak of path in btrfs_find_item" got sent
to stable trees, but in my testing, it causes deadlocks on mount:
[23379.359246] mount D 0 22541 22274 0x0080
[23379.366326] 8803ebadf6c8 0086 88027ff10230
00013680
[2
On 1/2/15 1:12 AM, Qu Wenruo wrote:
> Record every file extent discontinuous hole in inode_record using a
> rb_tree member.
>
> Before the patch, btrfsck will only record the first file extent hole by
> using first_extent_gap, that's good for detecting error, but not
> suitable for fixing it.
>
>
btrfs has started emitting new information from
cmd_subvol_delete(), so filter that out or it breaks btrfs/001:
-Delete subvolume 'SCRATCH_MNT/snap'
+Delete subvolume (no-commit): 'SCRATCH_MNT/snap'
(Spell "transaction" correctly while we're a
The btrfs cmd now sometimes emits "btrfs-progs" not "Btrfs-progs"
as it used to, so update the filter accordingly.
(This fixes a failure on btrfs/006 w/ btrfs-progs v3.19)
Signed-off-by: Eric Sandeen
---
diff --git a/common/filter.btrfs b/common/filter.btrfs
index c9b3f3a..
On 3/6/15 4:01 AM, Omar Sandoval wrote:
> Hi, Qu,
>
> I'm not seeing that in the code I'm looking at :( In fsfuzz:447, I see
> the mangle executable called with an offset starting at 0, which would
> mean that the superblock isn't safe.
(Semi-wild guess follows):
He may be using a hacked versi
On 3/5/15 3:46 AM, Liu Bo wrote:
> On Thu, Mar 05, 2015 at 03:09:33PM +0800, Eryu Guan wrote:
>> Hi,
>>
>> I was testing btrfs with fsfuzzer and encountered a divide error on
>> mount, kernel version 3.19 and 4.0-rc1.
>>
>> I found a similar bug on kernel bugzilla
>>
>> https://bugzilla.kernel.org/
tions more
> directly what the test does rather than the btrfs issue, which forced
> the reader to infer it and read the whole test.
Thanks. Ok, verified that it passes on ext4 and xfs, too -
Reviewed-by: Eric Sandeen
> tests/generic/060 | 172
> +++
On 2/24/15 5:29 PM, Filipe Manana wrote:
> This test is motivated by an fsync issue discovered in btrfs.
> The issue was that after adding a new hard link to an existing file
> (one that was created in a past transaction) and fsync'ing the parent
> directory of the new hard link, after the fsync lo
On 2/23/15 2:24 PM, Filipe David Manana wrote:
> On Mon, Feb 23, 2015 at 8:14 PM, Eric Sandeen wrote:
>> On 2/23/15 1:55 PM, Filipe Manana wrote:
>>> This test is motivated by an fsync issue discovered in btrfs.
>>> The issue was that the fsync log replay code did not
On 2/23/15 1:55 PM, Filipe Manana wrote:
> This test is motivated by an fsync issue discovered in btrfs.
> The issue was that the fsync log replay code did not remove xattrs that
> were deleted before the inode was fsynced. The result was unexpected
> and differed from xfs and ext3/4 for example.
>
On 2/23/15 6:20 AM, Austin S Hemmelgarn wrote:
> On 2015-02-20 21:56, Theodore Ts'o wrote:
>> On Fri, Feb 20, 2015 at 09:49:34AM -0600, Eric Sandeen wrote:
>>>
>>>>This mount option significantly reduces writes to the
>>>>
On 2/20/15 2:50 AM, Michael Kerrisk wrote:
> Hello Ted,
>
> Based on your commit message 0ae45f63d4e, I I wrote the documentation
> below for MS_LAZYTIME, to go into the mount(2) man page. Could you
> please check it over and let me know if it's accurate. In particular,
> I added pieces marked wit
On 2/9/15 2:03 PM, Josef Bacik wrote:
> The METADUMP super flag makes us skip doing the chunk tree reading which isn't
> helpful for the new restore since we have a valid chunk tree. But we still
> want
> to have a way for the kernel to know that this is a metadump restore so it
> doesn't do thin
On 2/5/15 2:31 PM, Eric Sandeen wrote:
> Disclaimer: I am not an auto$FOO expert by any means.
>
> But I could find no way to specify additional CFLAGS, and I think
> that this is because they are hard-coded in configure.ac.
>
> The below works for me, but I don't know if
Disclaimer: I am not an auto$FOO expert by any means.
But I could find no way to specify additional CFLAGS, and I think
that this is because they are hard-coded in configure.ac.
The below works for me, but I don't know if it's the right solution...
Signed-off-by: Eric Sandeen
---
di
On 12/30/14 10:06 PM, Wang Shilong wrote:
>
>>
>> Hello,
>>
>>>
>>> I have a well tested and working fine Centos5-Xen system. Accumulated cruft
>>> from various development efforts make it desirable to redo the install.
>>> Currently a RAID-10 ext4 filesystem with LVM and 750G of storage. There'
On 12/30/14 10:03 PM, Wang Shilong wrote:
> Hello,
>
>>
>> I have a well tested and working fine Centos5-Xen system.
>> Accumulated cruft from various development efforts make it
>> desirable to redo the install. Currently a RAID-10 ext4 filesystem
>> with LVM and 750G of storage. There's a hot sp
On 12/19/14 10:06 AM, David Sterba wrote:
> Same in kernel and matches semantics of free().
>
> Resolves-Coverity-CID: 1054881
> Signed-off-by: David Sterba
Reviewed-by: Eric Sandeen
> ---
> ctree.c | 2 ++
> 1 file changed, 2 insertions(+)
>
> diff --git
On 12/19/14 10:06 AM, David Sterba wrote:
> Resolves-Coverity-CID: 1054894
> Signed-off-by: David Sterba
Reviewed-by: Eric Sandeen
> ---
> cmds-send.c | 25 +
> 1 file changed, 21 insertions(+), 4 deletions(-)
>
> diff --git a/cmds-send.c
being defensive, I suppose, so:
Reviewed-by: Eric Sandeen
> Resolves-Coverity-CID: 1248828
> Signed-off-by: David Sterba
> ---
> cmds-check.c | 2 ++
> 1 file changed, 2 insertions(+)
>
> diff --git a/cmds-check.c b/cmds-check.c
> index 6eea36c2f52c..3e7a4ebdce44 100644
On 12/19/14 10:06 AM, David Sterba wrote:
> Resolves-Coverity-CID: 1258794
> Signed-off-by: David Sterba
Reviewed-by: Eric Sandeen
> ---
> btrfs-fragments.c | 7 +--
> 1 file changed, 5 insertions(+), 2 deletions(-)
>
> diff --git a/btrfs-fragments.c b/btrf
On 12/19/14 10:06 AM, David Sterba wrote:
> Resolves-Coverity-CID: 1258793
> Signed-off-by: David Sterba
Reviewed-by: Eric Sandeen
> ---
> btrfs-corrupt-block.c | 1 +
> 1 file changed, 1 insertion(+)
>
> diff --git a/btrfs-corrupt-block.c b/btrfs-corrupt-block.c
On 12/19/14 10:06 AM, David Sterba wrote:
> Using -I would imply -d.
>
> Resolves-Coverity-CID: 1258792
> Signed-off-by: David Sterba
Reviewed-by: Eric Sandeen
> ---
> btrfs-corrupt-block.c | 1 +
> 1 file changed, 1 insertion(+)
>
> diff --git a/btrfs-corr
1 - 100 of 623 matches
Mail list logo
