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
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
riate ioctl" can be caught in the
common case.
Signed-off-by: Eric Sandeen <sand...@redhat.com>
---
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
capa
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
riate ioctl" can be caught in the
common case.
Signed-off-by: Eric Sandeen <sand...@redhat.com>
---
(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:
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
riate ioctl" can be caught in the
common case.
Signed-off-by: Eric Sandeen <sand...@redhat.com>
---
(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:
riate ioctl" can be caught in the
common case.
Signed-off-by: Eric Sandeen <sand...@redhat.com>
---
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
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 ioc
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 <sand...@redhat.com>
Reviewed-by: Andreas Dilger
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 <sand...@redhat.com>
> ---
>
> V2: make primary file ioctl_getfslabel, link ioctl_
This documents the proposed new vfs-level ioctls which can
get or set a mounted filesytem's label.
Signed-off-by: Eric Sandeen <sand...@redhat.com>
---
V2: make primary file ioctl_getfslabel, link ioctl_setfslabel to it
note that getfslabel requires CAP_SYS_ADMIN
diff --git
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
This documents the proposed new vfs-level ioctls which can
get or set a mounted filesytem's label.
Signed-off-by: Eric Sandeen <sand...@redhat.com>
---
btrfs folks, please verify that this accurately describes your
current behavior, thanks.
diff --git a/man2/ioctl_fslabel.2 b/man2/ioctl_f
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 <sand...@redhat.com>
---
Let the bikesh
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 -
riate ioctl" can be caught in the
common case.
Signed-off-by: Eric Sandeen <sand...@redhat.com>
---
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
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)
>
>
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 comp
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" in
the body
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 <hall...@gmx.net>
Signed-off-by: Eric S
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, Ery
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
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 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
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 ker
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?
-E
against an old kernel, worst case scenario is that
no shared extents will be reported via the du command.
Signed-off-by: Eric Sandeen <sand...@redhat.com>
---
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-f
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
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 <sand...@redhat.com>
---
diff --git a/ioctl.h b/i
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
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:
On 9/1/16 7:44 AM, David Sterba wrote:
> Signed-off-by: David Sterba <dste...@suse.com>
Reviewed-by: Eric Sandeen <sand...@redhat.com>
> ---
> fs/btrfs/sysfs.c | 9 +
> 1 file changed, 9 insertions(+)
>
> diff --git a/fs/btrfs/sysfs.c b/fs/btrf
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
-by: Eric Sandeen <sand...@redhat.com>
---
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 -
it is 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
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
>
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).
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.
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
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
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
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 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
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 nore
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/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
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
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/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
On 10/21/15 4:09 AM, Qu Wenruo wrote:
>> +static int get_kernel_code()
>> +{
>> +int ret;
>> +struct utsname utsbuf;
>> +char *version;
>> +
>> +ret = uname();
>> +if (ret)
>> +return -ret;
>> +
>> +version = strtok(utsbuf.release, "-");
>> +
>> +return
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 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
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, but
On Jun 21, 2015, at 1:11 PM, Swâmi Petaramesh sw...@petaramesh.org 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
On 4/20/15 12:33 AM, xuw2...@gmail.com wrote:
From: George Wang xuw2...@gmail.com
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
.
Signed-off-by: Eric Sandeen sand...@redhat.com
---
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
xfs
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.bad
On 3/26/15 9:48 AM, Chris Mason wrote:
On Thu, Mar 26, 2015 at 10:11 AM, Eric Sandeen sand...@redhat.com wrote:
...
9c4f61f btrfs: simplify insert_orphan_item
made the whole path alloc/free go away.
so I think there's no need for my patch; may as well just send the above to
stable
.
Signed-off-by: Eric Sandeen sand...@redhat.com
---
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 /Performing full device
On 3/26/15 5:23 AM, Filipe David Manana wrote:
On Thu, Mar 26, 2015 at 3:24 AM, Eric Sandeen sand...@redhat.com 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.359246] mount D
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
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 at it.)
Signed-off-by: Eric Sandeen sand
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 sand...@redhat.com
---
diff --git a/common/filter.btrfs b/common/filter.btrfs
index c9b3f3a
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.
This
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 version
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
the whole test.
Thanks. Ok, verified that it passes on ext4 and xfs, too -
Reviewed-by: Eric Sandeen sand...@redhat.com
tests/generic/060 | 172
++
tests/generic/060.out | 11
tests/generic/group | 1 +
3 files changed, 184 insertions
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 log
On 2/23/15 2:24 PM, Filipe David Manana wrote:
On Mon, Feb 23, 2015 at 8:14 PM, Eric Sandeen sand...@sandeen.net 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 remove xattrs
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/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 with *
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 sand...@redhat.com
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 spare 750
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's a
hot spare
On 12/19/14 10:06 AM, David Sterba wrote:
Resolves-Coverity-CID: 1258793
Signed-off-by: David Sterba dste...@suse.cz
Reviewed-by: Eric Sandeen sand...@redhat.com
---
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 dste...@suse.cz
Reviewed-by: Eric Sandeen sand...@redhat.com
---
btrfs-corrupt-block.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/btrfs-corrupt
On 12/19/14 10:06 AM, David Sterba wrote:
Resolves-Coverity-CID: 1258794
Signed-off-by: David Sterba dste...@suse.cz
Reviewed-by: Eric Sandeen sand...@redhat.com
---
btrfs-fragments.c | 7 +--
1 file changed, 5 insertions(+), 2 deletions(-)
diff --git a/btrfs-fragments.c b/btrfs
, so:
Reviewed-by: Eric Sandeen sand...@redhat.com
Resolves-Coverity-CID: 1248828
Signed-off-by: David Sterba dste...@suse.cz
---
cmds-check.c | 2 ++
1 file changed, 2 insertions(+)
diff --git a/cmds-check.c b/cmds-check.c
index 6eea36c2f52c..3e7a4ebdce44 100644
--- a/cmds-check.c
On 12/19/14 10:06 AM, David Sterba wrote:
Resolves-Coverity-CID: 1054894
Signed-off-by: David Sterba dste...@suse.cz
Reviewed-by: Eric Sandeen sand...@redhat.com
---
cmds-send.c | 25 +
1 file changed, 21 insertions(+), 4 deletions(-)
diff --git a/cmds-send.c b
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 dste...@suse.cz
Reviewed-by: Eric Sandeen sand...@redhat.com
---
ctree.c | 2 ++
1 file changed, 2 insertions(+)
diff --git a/ctree.c b
On 12/18/14 7:31 AM, Karel Zak wrote:
On Wed, Dec 17, 2014 at 03:07:26PM +0100, David Sterba wrote:
On Fri, Dec 12, 2014 at 01:35:14PM +0100, Karel Zak wrote:
This is first step to make btrfs-progs build system more conventional
for userspace users and developers. All is implemented by small
On 12/11/14 6:37 AM, Holger Hoffstätte wrote:
David,
I was wondering if you could please send out announcements for btrfs-progs
when you tag a release or -rc? There doesn't seem to be a good mechanism
to track releases and IMHO the more people are notified, the more
testing we can get,
On Nov 20, 2014, at 10:44 PM, Eryu Guan eg...@redhat.com wrote:
On Wed, Nov 19, 2014 at 09:33:31AM -0600, Eric Sandeen wrote:
A couple tests exercise replace but were not marked as such
in the group file.
Hi Eric,
I have a patch sitting in my git tree that adds most of btrfs tests
A couple tests exercise replace but were not marked as such
in the group file.
Signed-off-by: Eric Sandeen sand...@redhat.com
---
diff --git a/tests/btrfs/group b/tests/btrfs/group
index 9adf862..1f23979 100644
--- a/tests/btrfs/group
+++ b/tests/btrfs/group
@@ -13,7 +13,7 @@
008 auto quick
On 10/28/14 9:19 PM, Chris Murphy wrote:
3.18.0-0.rc2.git1.1.fc22.x86_64
btrfs-progs-3.17-1.fc21.x86_64
# btrfs fi show /mnt
Label: 'btrfs1' uuid: 0f1c615f-30a0-4166-8a3c-987849551513
Total devices 2 FS bytes used 233.54GiB
devid1 size 465.76GiB used 236.03GiB path
On 10/16/14 6:46 AM, David Sterba wrote:
On Wed, Oct 15, 2014 at 04:14:17PM -0700, Zach Brown wrote:
Here's another set of coverity fixes for btrfs-progs against David's
integration-20141007 branch.
Thanks, I've fished 2 patches for 3.17, the rest is queued.
I got tired of adding error
On 10/10/14 2:35 PM, Austin S Hemmelgarn wrote:
On 2014-10-10 13:43, Bob Marley wrote:
On 10/10/2014 16:37, Chris Murphy wrote:
The fail safe behavior is to treat the known good tree root as
the default tree root, and bypass the bad tree root if it cannot
be repaired, so that the volume can
On 10/9/14 8:49 AM, Duncan wrote:
Austin S Hemmelgarn posted on Thu, 09 Oct 2014 09:18:22 -0400 as
excerpted:
On 2014-10-09 08:34, Duncan wrote:
The only way a read-only
mount should be writable is if it's mounted (bind-mounted or
btrfs-subvolume-mounted) read-write elsewhere, and the
I was looking at Marc's post:
http://marc.merlins.org/perso/btrfs/post_2014-03-19_Btrfs-Tips_-Btrfs-Scrub-and-Btrfs-Filesystem-Repair.html
and it feels like there isn't exactly a cohesive, overarching vision for
repair of a corrupted btrfs filesystem.
In other words - I'm an admin cruising
will be set in the real mount time and won't lose
label when use with subvol= mount option.
Thanks for working on this. Eric Sandeen (cc'd) was trying out
something similar recently, so I want to make sure this doesn't conflict
with his ideas.
My ideas didn't get very far. ;)
What I was after
On 9/23/14 7:31 PM, Qu Wenruo wrote:
Original Message
Subject: Re: [PATCH] btrfs: Make btrfs handle security mount options
internally to avoid losing security label.
From: Eric Sandeen sand...@redhat.com
To: Chris Mason c...@fb.com, Qu Wenruo quwen...@cn.fujitsu.com
fs_devices memory
have been freed before we free it.
Cc: Eric Sandeen sand...@redhat.com
Cc: Chris Murphy li...@colorremedies.com
Signed-off-by: Wang Shilong wangshilong1...@gmail.com
That does seem to fix the testcase. Thanks!
Acked-by: Eric Sandeen sand...@redhat.com
---
super-recover.c | 13
1 - 100 of 574 matches
Mail list logo
