On Fri, Nov 23, 2018 at 2:52 PM Jan Kara wrote:
>
> Changed subject to better match what we discuss and added btrfs list to CC.
>
> On Thu 22-11-18 17:18:25, Amir Goldstein wrote:
> > On Thu, Nov 22, 2018 at 3:26 PM Jan Kara wrote:
> > >
> > > On Thu 22-
On Fri, Nov 23, 2018 at 3:34 PM Amir Goldstein wrote:
>
> On Fri, Nov 23, 2018 at 2:52 PM Jan Kara wrote:
> >
> > Changed subject to better match what we discuss and added btrfs list to CC.
> >
> > On Thu 22-11-18 17:18:25, Amir Goldstein wrote:
> > > O
On Fri, Oct 5, 2018 at 3:46 AM Darrick J. Wong wrote:
>
> From: Darrick J. Wong
>
> Clone range is an optimization on a regular file write. File writes
> that extend the file length are subject to various constraints which are
> not checked by clonerange. This is a correctness problem, because
On Fri, Oct 5, 2018 at 3:46 AM Darrick J. Wong wrote:
>
> From: Darrick J. Wong
>
> For a given dedupe request, the bytes_deduped field in the control
> structure tells userspace if we managed to deduplicate some, but not all
> of, the requested regions starting from the file offsets supplied.
>
On Fri, Oct 5, 2018 at 3:46 AM Darrick J. Wong wrote:
>
> From: Darrick J. Wong
>
> Use the new CLONE_RANGE_EOF flag to explicitly declare that the caller
> wants the clone implementation to set *len appropriately once the files
> are locked.
>
> Signed-off-by: Darrick J. Wong
> ---
> fs/read_w
On Fri, Oct 5, 2018 at 3:46 AM Darrick J. Wong wrote:
>
> From: Darrick J. Wong
>
> Pass operational flags to the per-filesystem clone and dedupe
> implementations. This enables the vfs to signal when it can deal with
> short clone and short dedupe operations.
>
> Signed-off-by: Darrick J. Wong
On Fri, Oct 5, 2018 at 3:46 AM Darrick J. Wong wrote:
>
> From: Darrick J. Wong
>
> Change the clone_file_range and dedupe_file_range functions to return
> the number of bytes they operated on. This is the precursor to allowing
> fs implementations to return short clone/dedupe results to the use
On Fri, Oct 5, 2018 at 3:46 AM Darrick J. Wong wrote:
>
> From: Darrick J. Wong
>
> Don't bother calling the filesystem for a zero-length dedupe request;
> we can return zero and exit.
>
> Signed-off-by: Darrick J. Wong
> ---
> fs/read_write.c |5 +
> 1 file changed, 5 insertions(+)
>
>
On Wed, Oct 10, 2018 at 3:11 AM Darrick J. Wong wrote:
>
> From: Darrick J. Wong
>
> File range remapping, if allowed to run past the destination file's EOF,
> is an optimization on a regular file write. Regular file writes that
> extend the file length are subject to various constraints which a
On Wed, Oct 10, 2018 at 3:12 AM Darrick J. Wong wrote:
>
> From: Darrick J. Wong
>
> Combine the clone_file_range and dedupe_file_range operations into a
> single remap_file_range file operation dispatch since they're
> fundamentally the same operation. The differences between the two can
> be m
On Wed, Oct 10, 2018 at 3:14 AM Darrick J. Wong wrote:
>
> From: Darrick J. Wong
>
> Plumb a remap_flags argument through the {do,vfs}_clone_file_range
> functions so that clone can take advantage of it.
>
> Signed-off-by: Darrick J. Wong
> ---
[...]
> diff --git a/fs/overlayfs/file.c b/fs/overl
On Wed, Oct 10, 2018 at 9:22 AM Amir Goldstein wrote:
>
> On Wed, Oct 10, 2018 at 3:14 AM Darrick J. Wong
> wrote:
> >
> > From: Darrick J. Wong
> >
> > Plumb a remap_flags argument through the {do,vfs}_clone_file_range
> > functions so that clone can t
On Wed, Oct 10, 2018 at 3:14 AM Darrick J. Wong wrote:
>
> From: Darrick J. Wong
>
> Change the remap_file_range functions to take a number of bytes to
> operate upon and return the number of bytes they operated on. This is a
> requirement for allowing fs implementations to return short clone/de
On Wed, Oct 10, 2018 at 3:14 AM Darrick J. Wong wrote:
>
> From: Darrick J. Wong
>
> Create a RFR_TO_SRC_EOF flag to explicitly declare that the caller wants
> the remap implementation to remap to the end of the source file, once
> the files are locked.
>
> Signed-off-by: Darrick J. Wong
> ---
>
On Wed, Oct 10, 2018 at 6:13 PM Darrick J. Wong wrote:
>
> On Wed, Oct 10, 2018 at 08:54:44AM +0300, Amir Goldstein wrote:
> > On Wed, Oct 10, 2018 at 3:12 AM Darrick J. Wong
> > wrote:
> > >
> > > From: Darrick J. Wong
> > >
> > > Combine
On Wed, Oct 10, 2018 at 8:01 PM Darrick J. Wong wrote:
>
> On Wed, Oct 10, 2018 at 08:23:27AM +0300, Amir Goldstein wrote:
> > On Wed, Oct 10, 2018 at 3:11 AM Darrick J. Wong
> > wrote:
> > >
> > > From: Darrick J. Wong
> > >
> > > File r
On Wed, Oct 10, 2018 at 7:29 PM Darrick J. Wong wrote:
>
> On Wed, Oct 10, 2018 at 03:29:06PM +0300, Amir Goldstein wrote:
> > On Wed, Oct 10, 2018 at 3:14 AM Darrick J. Wong
> > wrote:
> > >
> > > From: Darrick J. Wong
> > >
> > > Creat
On Wed, Oct 10, 2018 at 6:51 PM Darrick J. Wong wrote:
>
> On Wed, Oct 10, 2018 at 09:47:00AM +0300, Amir Goldstein wrote:
> > On Wed, Oct 10, 2018 at 3:14 AM Darrick J. Wong
> > wrote:
> > >
> > > From: Darrick J. Wong
> > >
> > > Cha
> > +/*
> > + * These flags control the behavior of the remap_file_range function
> > pointer.
> > + *
> > + * RFR_SAME_DATA: only remap if contents identical (i.e. deduplicate)
> > + */
> > +#define RFR_SAME_DATA(1 << 0)
> > +
> > +#define RFR_VALID_FLAGS (RFR_SAME_DA
On Mon, Oct 15, 2018 at 3:47 PM Christoph Hellwig wrote:
>
> On Mon, Oct 15, 2018 at 09:04:13AM +0300, Amir Goldstein wrote:
> > I supposed you figured out the reason already.
>
> No, I hadn't.
>
> > It makes it appearance in patch 16/25 as RFR_VFS_FLAGS.
> &g
On Mon, Oct 22, 2018 at 8:09 AM Dave Chinner wrote:
>
> On Mon, Oct 22, 2018 at 05:52:49AM +0100, Al Viro wrote:
> > On Mon, Oct 22, 2018 at 03:37:41PM +1100, Dave Chinner wrote:
> >
> > > Ok, this is a bit of a mess. the patches do not merge cleanly to a
> > > 4.19-rc1 base kernel because of all
On Fri, Feb 15, 2019 at 4:23 AM Darrick J. Wong wrote:
>
> From: Darrick J. Wong
>
> d_tmpfile was introduced to instantiate an inode in the dentry cache as
> a temporary file. This helper decrements the inode's nlink count and
> dirties the inode, presumably so that filesystems could call new_i
On Fri, Jun 28, 2019 at 9:37 PM Darrick J. Wong wrote:
>
> From: Darrick J. Wong
>
> The chattr manpage has this to say about immutable files:
>
> "A file with the 'i' attribute cannot be modified: it cannot be deleted
> or renamed, no link can be created to this file, most of the file's
> metada
ints on supposedly immutable files. Therefore, reject setflags
> and fssetxattr calls on an immutable file if the file is immutable and
> will remain that way.
>
> Signed-off-by: Darrick J. Wong
> ---
> v2: use memcmp instead of open coding a bunch of checks
Thanks,
Reviewed-b
On Mon, Feb 26, 2018 at 9:31 AM, Qu Wenruo wrote:
> This test case is originally designed to expose unexpected corruption
> for btrfs, where there are several reports about btrfs serious metadata
> corruption after power loss.
>
> The test case itself will trigger heavy fsstress for the fs, and us
On Mon, Feb 26, 2018 at 10:20 AM, Qu Wenruo wrote:
>
>
> On 2018年02月26日 16:15, Amir Goldstein wrote:
>> On Mon, Feb 26, 2018 at 9:31 AM, Qu Wenruo wrote:
>>> This test case is originally designed to expose unexpected corruption
>>> for btrfs, where there are se
On Mon, Feb 26, 2018 at 10:41 AM, Qu Wenruo wrote:
>
>
> On 2018年02月26日 16:33, Amir Goldstein wrote:
>> On Mon, Feb 26, 2018 at 10:20 AM, Qu Wenruo wrote:
>>>
>>>
>>> On 2018年02月26日 16:15, Amir Goldstein wrote:
>>>> On Mon, Feb 26, 2018
On Mon, Feb 26, 2018 at 3:01 PM, Nikolay Borisov wrote:
> [CCing Amir since he touched precisely the code responsible for this
> semantics]
[CCing fsdevel and NFS list since there is already a long standing attempt
to relax the copy_file_range() API for cross server copy]
>
> On 26.02.2018 14:0
On Tue, Mar 6, 2018 at 10:15 AM, Qu Wenruo wrote:
> Also change the flag numeric output to hex.
>
> Signed-off-by: Qu Wenruo
> ---
> src/log-writes/log-writes.c | 70
> -
> 1 file changed, 63 insertions(+), 7 deletions(-)
>
> diff --git a/src/log-writ
On Tue, Mar 6, 2018 at 10:15 AM, Qu Wenruo wrote:
> There are some btrfs corruption report in mail list for a while,
> although such corruption is pretty rare and almost impossible to
> reproduce, with dm-log-writes we found it's highly related to v1 space
> cache.
>
> Unlike journal based filesys
On Wed, Mar 14, 2018 at 11:02 AM, Qu Wenruo wrote:
> Also change the flag numeric output to hex.
>
> Signed-off-by: Qu Wenruo
Reviewed-by: Amir Goldstein
> ---
> src/log-writes/log-writes.c | 70
> -
> 1 file changed, 63 inser
On Wed, Mar 14, 2018 at 11:02 AM, Qu Wenruo wrote:
> Signed-off-by: Qu Wenruo
Reviewed-by: Amir Goldstein
> ---
> src/log-writes/log-writes.c | 3 ++-
> src/log-writes/log-writes.h | 9 +
> 2 files changed, 7 insertions(+), 5 deletions(-)
>
> diff --git a/src/log-
On Wed, Mar 14, 2018 at 11:02 AM, Qu Wenruo wrote:
> Basic test case which triggers fsstress with dm-log-writes, and then
> check the fs after each FUA writes.
> With needed infrastructure and special handlers for journal based fs.
>
> Signed-off-by: Qu Wenruo
> ---
> In my test, xfs and btrfs su
On Fri, Mar 16, 2018 at 10:19 AM, Eryu Guan wrote:
> On Fri, Mar 16, 2018 at 01:17:07PM +0800, Qu Wenruo wrote:
>>
>>
>> On 2018年03月16日 12:01, Eryu Guan wrote:
>> > On Wed, Mar 14, 2018 at 05:02:30PM +0800, Qu Wenruo wrote:
>> >> Basic test case which triggers fsstress with dm-log-writes, and then
On Wed, Mar 21, 2018 at 10:01 AM, Qu Wenruo wrote:
> Basic test case which triggers fsstress with dm-log-writes, and then
> check the fs after each FUA writes.
> With needed infrastructure and special handlers for journal based fs.
>
> Signed-off-by: Qu Wenruo
> ---
> Unfortunately, neither xfs n
if total test run time is expected to be under 10min I wouldn't
bother with this optimization, at least not right now. IMO it is more
important to get the test out there to get the corruption bugs floating.
Thanks for working on this!
You can add
Reviewed-by: Amir Goldstein
>
> As a com
On Thu, Apr 12, 2018 at 8:51 PM, Jayashree Mohan
wrote:
> Hi,
>
> We came across what seems to be a crash consistency bug on btrfs and
> f2fs. When we create a symlink for a file and fsync the symlink, on
> recovery from crash, the fsync-ed file is missing.
>
> You can reproduce this behaviour usi
On Fri, Apr 13, 2018 at 3:54 PM, Vijay Chidambaram wrote:
> Hi Amir,
>
> Thanks for the reply!
>
> On Fri, Apr 13, 2018 at 12:52 AM, Amir Goldstein wrote:
>>
>> Not a bug.
>>
>> From man 2 fsync:
>>
>> "Calling fsync() does not necessari
On Mon, Apr 16, 2018 at 3:10 AM, Vijay Chidambaram wrote:
[...]
> Consider the following workload:
>
> creat foo
> link (foo, A/bar)
> fsync(foo)
> crash
>
> In this case, after the file system recovers, do we expect foo's link
> count to be 2 or 1? I would say 2, but POSIX is silent on this,
CC: Ted
What ever happened to read/write ext4 encrypted data API?
https://marc.info/?l=linux-ext4&m=145030599010416&w=2
Can we learn anything from the ext4 experience to improve
the new proposed API?
On Wed, Oct 16, 2019 at 12:29 AM Omar Sandoval wrote:
>
> From: Omar Sandoval
>
> This adds a
On Mon, Oct 21, 2019 at 9:54 PM Omar Sandoval wrote:
>
> On Mon, Oct 21, 2019 at 09:18:13AM +0300, Amir Goldstein wrote:
> > CC: Ted
> >
> > What ever happened to read/write ext4 encrypted data API?
> > https://marc.info/?l=linux-ext4&m=145030599010416&w=2
On Tue, Oct 22, 2019 at 11:00 AM Qu Wenruo wrote:
>
> There is a fs corruption report of a tree block in use get trimmed, and
> cause fs corruption.
>
> Although I haven't found the cause from the source code, it won't hurt
> to add such test case.
>
> The test case is limited to btrfs due to the
> >
> > No, I see why you choose to add the flag to open(2).
> > I have no objection.
> >
> > I once had a crazy thought how to add new open flags
> > in a non racy manner without adding a new syscall,
> > but as you wrote, this is not relevant for O_ALLOW_ENCODED.
> >
> > Something like:
> >
> > /
On Wed, Aug 1, 2018 at 12:10 AM, Mark Fasheh wrote:
> /proc/locks does not always print the correct inode number/device pair.
> Update lock_get_status() to use vfs_map_unique_ino_dev() to get the real,
> unique values for userspace.
>
> Signed-off-by: Mark Fasheh
> ---
> fs/locks.c | 12
On Wed, Aug 1, 2018 at 2:21 AM, Mark Fasheh wrote:
>
> On Tue, Jul 31, 2018 at 02:10:42PM -0700, Mark Fasheh wrote:
>> diff --git a/fs/stat.c b/fs/stat.c
>> index f8e6fb2c3657..80ea42505219 100644
>> --- a/fs/stat.c
>> +++ b/fs/stat.c
>> @@ -84,6 +84,29 @@ int vfs_getattr_nosec(const struct path *
we run up against
> alignment problems, resource limits, etc.).
>
> Signed-off-by: Darrick J. Wong
> Reviewed-by: Amir Goldstein
> ---
> fs/read_write.c| 15 +--
> include/linux/fs.h |7 +--
> mm/filemap.c | 16
> 3
On Thu, Oct 11, 2018 at 7:12 AM Darrick J. Wong wrote:
>
> Hi all,
>
> Dave, Eric, and I have been chasing a stale data exposure bug in the XFS
> reflink implementation, and tracked it down to reflink forgetting to do
> some of the file-extending activities that must happen for regular
> writes.
>
On Thu, Oct 11, 2018 at 4:43 PM Christoph Hellwig wrote:
>
> > -EXPORT_SYMBOL(vfs_clone_file_prep_inodes);
> > +EXPORT_SYMBOL(vfs_clone_file_prep);
>
> Btw, why isn't this EXPORT_SYMBOL_GPL? It is rather Linux internal
> code, including some that I wrote which you lifted into the core
> in "vfs:
On Sat, Apr 10, 2021 at 1:04 AM Chris Murphy wrote:
>
> Hi,
>
> The primary problem is Bolt (Thunderbolt 3) tests that are
> experiencing a regression when run in a container using overlayfs,
> failing at:
>
> Bail out! ERROR:../tests/test-common.c:1413:test_io_dir_is_empty:
> 'empty' should be FA
_dir_is_empty also has more
> instances of this line, but I don't know they are related. So I'll
> keep looking into that.
>
>
> On Sat, Apr 10, 2021 at 2:04 AM Amir Goldstein wrote:
>
> > As the first step, can you try the suggested fix to ovl_dentry_version
On Mon, Mar 4, 2019 at 4:44 PM wrote:
>
> From: Filipe Manana
>
> Test that if we truncate a file to reduce its size, rename it and then
> fsync it, after a power failure the file has a correct size and name.
>
I am not sure that ext4/xfs semantics guaranty anything about
persisting file name af
On Mon, Mar 4, 2019 at 5:23 PM Filipe Manana wrote:
>
> On Mon, Mar 4, 2019 at 3:04 PM Amir Goldstein wrote:
> >
> > On Mon, Mar 4, 2019 at 4:44 PM wrote:
> > >
> > > From: Filipe Manana
> > >
> > > Test that if we truncate a file to reduc
On Tue, Mar 5, 2019 at 2:50 AM Dave Chinner wrote:
>
> On Mon, Mar 04, 2019 at 05:04:23PM +0200, Amir Goldstein wrote:
> > On Mon, Mar 4, 2019 at 4:44 PM wrote:
> > >
> > > From: Filipe Manana
> > >
> > > Test that if we truncate a file to re
On Tue, Mar 5, 2019 at 12:31 AM Filipe Manana wrote:
>
> On Mon, Mar 4, 2019 at 5:59 PM Amir Goldstein wrote:
> >
> > On Mon, Mar 4, 2019 at 5:23 PM Filipe Manana wrote:
> > >
> > > On Mon, Mar 4, 2019 at 3:04 PM Amir Goldstein wrote:
> > > &g
> > As I wrote to Dave, if file is not "metadata dirty" before rename,
> > then whether or not rename dirties to file for fsync is a filesystem
> > specific implementation detail that is not in any standard.
> >
> > Since filesystems tend to try to optimize out unneeded journal
> > commits, so the
On Wed, Mar 6, 2019 at 12:33 AM Dave Chinner wrote:
>
> On Tue, Mar 05, 2019 at 07:39:28AM +0200, Amir Goldstein wrote:
> > On Tue, Mar 5, 2019 at 2:50 AM Dave Chinner wrote:
> > >
> > > On Mon, Mar 04, 2019 at 05:04:23PM +0200, Amir Goldstein wrote:
> > >
On Wed, Mar 6, 2019 at 11:48 PM Dave Chinner wrote:
>
> On Wed, Mar 06, 2019 at 09:51:23AM +0200, Amir Goldstein wrote:
> > On Wed, Mar 6, 2019 at 12:33 AM Dave Chinner wrote:
> > > > So the reason this is working is because 2nd fsync needs to
> > > > persist
On Thu, Mar 28, 2019 at 7:51 PM Darrick J. Wong wrote:
>
> From: Darrick J. Wong
>
> The chattr manpage has this to say about immutable files:
>
> "A file with the 'i' attribute cannot be modified: it cannot be deleted
> or renamed, no link can be created to this file, most of the file's
> metada
On Thu, Mar 28, 2019 at 7:36 AM Qu Wenruo wrote:
>
> For kernel operation we have METADATA/FUA/FLUSH flags as a beacon, but
> for user space write we don't have any useful flag unless the user space
> tool call fsync() to generate a FLUSH bio.
>
> This means for user space write, we don't really h
On Sun, Apr 7, 2019 at 11:28 PM Darrick J. Wong wrote:
>
> From: Darrick J. Wong
>
> The chattr manpage has this to say about immutable files:
>
> "A file with the 'i' attribute cannot be modified: it cannot be deleted
> or renamed, no link can be created to this file, most of the file's
> metada
On Tue, Apr 9, 2019 at 6:19 AM Darrick J. Wong wrote:
>
> From: Darrick J. Wong
>
> The chattr manpage has this to say about immutable files:
>
> "A file with the 'i' attribute cannot be modified: it cannot be deleted
> or renamed, no link can be created to this file, most of the file's
> metadat
New link flags to request "atomic" link.
Signed-off-by: Amir Goldstein
---
Hi Guys,
Following our discussions on LSF/MM and beyond [1][2], here is
an RFC documentation patch.
Ted, I know we discussed limiting the API for linking an O_TMPFILE
to avert the hardlinks issue, but I
On Tue, May 28, 2019 at 11:27 PM Theodore Ts'o wrote:
>
> On Mon, May 27, 2019 at 08:26:55PM +0300, Amir Goldstein wrote:
> >
> > Following our discussions on LSF/MM and beyond [1][2], here is
> > an RFC documentation patch.
> >
> > Ted, I know we
On Tue, May 28, 2019 at 11:07 PM Darrick J. Wong
wrote:
>
> On Mon, May 27, 2019 at 08:26:55PM +0300, Amir Goldstein wrote:
> > New link flags to request "atomic" link.
> >
> > Signed-off-by: Amir Goldstein
> > ---
> >
> > Hi Guys,
> >
> >
> > So instead of saying "A filesystem that accepts this flag will
> > guaranty, that old inode data will not be exposed in the new linked
> > name." It's much clearer to state this in the affirmative:
> >
> > A filesystem which accepts this flag will guarantee that if
> > the
On Fri, May 31, 2019 at 7:41 PM Theodore Ts'o wrote:
>
> On Fri, May 31, 2019 at 06:21:45PM +0300, Amir Goldstein wrote:
> > What do you think of:
> >
> > "AT_ATOMIC_DATA (since Linux 5.x)
> > A filesystem which accepts this flag will guarantee that if
On Sat, Jun 1, 2019 at 1:46 AM Dave Chinner wrote:
>
> On Fri, May 31, 2019 at 12:41:36PM -0400, Theodore Ts'o wrote:
> > On Fri, May 31, 2019 at 06:21:45PM +0300, Amir Goldstein wrote:
> > > What do you think of:
> > >
> > > "AT_ATOMIC_DATA (since
On Sat, Jun 1, 2019 at 2:28 AM Dave Chinner wrote:
>
> On Sat, Jun 01, 2019 at 08:45:49AM +1000, Dave Chinner wrote:
> > Given that we can already use AIO to provide this sort of ordering,
> > and AIO is vastly faster than synchronous IO, I don't see any point
> > in adding complex barrier interfa
> > Actually, one of my use cases is "atomic rename" of files with
> > no data (looking for atomicity w.r.t xattr and mtime), so this "atomic
> > rename"
> > thread should not be interfering with other workloads at all.
>
> Which should already guaranteed because a) rename is supposed to be
> atom
On Sat, May 12, 2018 at 3:06 AM, Darrick J. Wong
wrote:
> On Fri, May 11, 2018 at 12:26:51PM -0700, Mark Fasheh wrote:
>> Right now we return EINVAL if a process does not have permission to dedupe a
>> file. This was an oversight on my part. EPERM gives a true description of
>> the nature of our e
On Thu, Jun 7, 2018 at 12:38 AM, Mark Fasheh wrote:
> Hi,
>
> We have an inconsistency in how the kernel is exporting inode number /
> device pairs for user space. There's of course stat(2) and statx(2),
> but aside from those we simply dump inode->i_ino and super->s_dev. In
> some cases, the dump
On Fri, Jun 8, 2018 at 12:06 AM, Mark Fasheh wrote:
[...]
>> > 2c) I don't think we can really use a dedicated callback without
>> > passing the vfsmount through since Overlayfs ->getattr might call
>> > the lower fs ->getattr. At that point we might as well use getattr.
>> >
>>
>> Did
On Wed, Dec 21, 2016 at 7:03 PM, Jeff Layton wrote:
> The spinlock is only used to serialize callers that want to increment
> the counter. We can achieve the same thing with an atomic64_t and
> get the i_lock out of this codepath.
>
Cool work! See some nits and suggestions below.
> +/*
> + * We
On Wed, Apr 5, 2017 at 3:30 PM, David Sterba wrote:
> On Wed, Apr 05, 2017 at 11:53:41AM +0100, David Howells wrote:
>> I've added a test to xfstests that exercises the new statx syscall. However,
>> it fails on btrfs:
>>
>> Test statx on a directory
>> +[!] stx_nlink differs, 1 != 2
>>
On Wed, Aug 16, 2017 at 10:06 PM, Vijay Chidambaram wrote:
> Hi Josef,
>
> Thank you for the detailed reply -- I think it provides several
> pointers for our future work. It sounds like we have a similar vision
> for where we want this to go, though we may disagree about how to
> implement this :)
On Fri, Sep 1, 2017 at 10:04 AM, Eryu Guan wrote:
> On Fri, Sep 01, 2017 at 02:39:44PM +0900, Misono, Tomohiro wrote:
>> Several tests uses both _filter_test_dir and _filter_scratch
>> concatenated by pipe to filter $TEST_DIR and $SCRATCH_MNT. However, this
>> would fail if the shorter string is a
On Wed, Mar 16, 2011 at 1:35 AM, Chris Mason wrote:
> Excerpts from Andreas Dilger's message of 2011-03-15 18:06:49 -0400:
>> On 2011-03-15, at 2:57 PM, Christoph Hellwig wrote:
>> > On Tue, Mar 15, 2011 at 04:26:50PM -0400, Chris Mason wrote:
>> >> #define FS_EXTENT_FL 0x0008 /* Exte
On Thu, Mar 17, 2011 at 4:21 PM, Chris Mason wrote:
> Excerpts from liubo's message of 2011-03-16 22:10:09 -0400:
>> On 03/16/2011 05:06 PM, Amir Goldstein wrote:
>> > On Wed, Mar 16, 2011 at 1:35 AM, Chris Mason
>> > wrote:
>> >> Excerpts from And
Hi Anand,
Can you please post the patch in the body of the message so we can
comment on it inline.
Aditya is also working on a btrfs snapshots xfstest (currently named
257) as part of
his Google summer of code project.
It would be great if you guys can cooperate your efforts.
BTW, while running
79 matches
Mail list logo
