On Oct 1, 2018, at 9:49 AM, Eric Sandeen wrote:
>
>
> 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
On May 18, 2018, at 1:10 PM, Kent Overstreet <kent.overstr...@gmail.com> wrote:
>
> On Fri, May 18, 2018 at 01:05:20PM -0600, Andreas Dilger wrote:
>> On May 18, 2018, at 1:49 AM, Kent Overstreet <kent.overstr...@gmail.com>
>> wrote:
>>>
>>&
On May 18, 2018, at 1:49 AM, Kent Overstreet wrote:
>
> Signed-off-by: Kent Overstreet
I agree with Christoph that even if there was some explanation in the cover
letter, there should be something at least as good in the patch itself. The
efine FS_IOC_FSSETXATTR _IOW('X', 32, struct fsxattr)
>
> Separate patch for whitespace cleanup.
Really? I've heard Ted complain the other way, that whitespace cleanup
by itself is useless and should only be done as part of other changes.
As long as it is not overwhelming t
[remove stable@ as this is not really a stable patch]
On Dec 14, 2017, at 7:30 AM, Yan, Zheng wrote:
>
> On Thu, Dec 14, 2017 at 9:43 PM, Jan Kara wrote:
>> On Thu 14-12-17 18:55:27, Yan, Zheng wrote:
>>> We recently got an Oops report:
>>>
>>> BUG: unable to
On Nov 15, 2017, at 7:18 PM, Qu Wenruo wrote:
>
> [Background]
> Recently I'm considering the possibility to use checksum from filesystem
> to enhance device-mapper raid.
>
> The idea behind it is quite simple, since most modern filesystems have
> checksum for their
On May 10, 2017, at 11:10 PM, Eric Biggers wrote:
>
> On Wed, May 10, 2017 at 01:14:37PM -0700, Darrick J. Wong wrote:
>> [cc btrfs, since afaict that's where most of the dedupe tool authors hang
>> out]
>>
>> On Wed, May 10, 2017 at 02:27:33PM -0500, Eric W. Biederman
On Jan 17, 2017, at 8:59 AM, Theodore Ts'o wrote:
>
> On Tue, Jan 17, 2017 at 04:18:17PM +0100, Michal Hocko wrote:
>>
>> OK, so I've been staring into the code and AFAIU current->journal_info
>> can contain my stored information. I could either hijack part of the
>> word as the
On Jan 11, 2017, at 3:29 AM, Miklos Szeredi wrote:
>
> I know there's work on this for xfs, but could this be done in generic mm
> code?
>
> What are the obstacles? page->mapping and page->index are the obvious ones.
>
> If that's too difficult is it maybe enough to share
On Nov 9, 2016, at 1:56 PM, Jaegeuk Kim wrote:
>
> This patch implements multiple devices support for f2fs.
> Given multiple devices by mkfs.f2fs, f2fs shows them entirely as one big
> volume under one f2fs instance.
>
> Internal block management is very simple, but we will
On Oct 25, 2016, at 4:44 PM, Omar Sandoval wrote:
>
> On Tue, Oct 25, 2016 at 02:41:44PM -0400, Josef Bacik wrote:
>> With anything that populates the inode/dentry cache with a lot of one time
>> use
>> inodes we can really put a lot of pressure on the system for things we
> On Jul 6, 2016, at 10:33 AM, Joerg Schilling
> wrote:
>
> "Austin S. Hemmelgarn" wrote:
>
>> On 2016-07-06 11:22, Joerg Schilling wrote:
>>>
>>>
>>> You are mistaken.
>>>
>>> stat /proc/$$/as
>>> File: `/proc/6518/as'
>>>
On Jul 2, 2016, at 1:18 AM, Pavel Raiskup wrote:
>
> There are optimizations in archivers (tar, rsync, ...) that rely on up2date
> st_blocks info. For example, in GNU tar there is optimization check [1]
> whether the 'st_size' reports more data than the 'st_blocks' can hold
On Apr 27, 2016, at 5:54 AM, Michal Hocko wrote:
>
> From: Michal Hocko
>
> xfs has defined PF_FSTRANS to declare a scope GFP_NOFS semantic quite
> some time ago. We would like to make this concept more generic and use
> it for other filesystems as well.
On Mar 31, 2016, at 12:08 PM, J. Bruce Fields wrote:
>
> On Thu, Mar 31, 2016 at 10:18:50PM +1100, Dave Chinner wrote:
>> On Thu, Mar 31, 2016 at 12:54:40AM -0700, Christoph Hellwig wrote:
>>> On Thu, Mar 31, 2016 at 12:18:13PM +1100, Dave Chinner wrote:
On Wed, Mar
On Mar 31, 2016, at 1:55 AM, Christoph Hellwig wrote:
>
> On Wed, Mar 30, 2016 at 05:32:42PM -0700, Liu Bo wrote:
>> Well, btrfs fallocate doesn't allocate space if it's a shared one
>> because it thinks the space is already allocated. So a later overwrite
>> over this
> On Oct 24, 2015, at 10:52 AM, Eric Biggers wrote:
>
> A few comments:
>
>> if (!(file_in->f_mode & FMODE_READ) ||
>> !(file_out->f_mode & FMODE_WRITE) ||
>> (file_out->f_flags & O_APPEND) ||
>> !file_out->f_op)
>> return
> On Oct 16, 2015, at 3:08 PM, Anna Schumaker wrote:
>
> copy_file_range() is a new system call for copying ranges of data
> completely in the kernel. This gives filesystems an opportunity to
> implement some kind of "copy acceleration", such as reflinks or
>
On Sep 4, 2015, at 2:16 PM, Anna Schumaker wrote:
>
> Copy system calls came up during Plumbers a couple of weeks ago,
> because several filesystems (including NFS and XFS) are currently
> working on copy acceleration implementations. We haven't heard from
> Zach
On Sep 4, 2015, at 3:38 PM, Darrick J. Wong wrote:
>
> On Fri, Sep 04, 2015 at 04:17:03PM -0400, Anna Schumaker wrote:
>> copy_file_range() is a new system call for copying ranges of data
>> completely in the kernel. This gives filesystems an opportunity to
>> implement
On Aug 5, 2015, at 3:51 AM, mho...@kernel.org wrote:
Hi,
small GFP_NOFS, like GFP_KERNEL, allocations have not been not failing
traditionally even though their reclaim capabilities are restricted
because the VM code cannot recurse into filesystems to clean dirty
pages. At the same time these
On Apr 10, 2015, at 4:00 PM, Zach Brown z...@redhat.com wrote:
Add a copy_file_range() system call for offloading copies between
regular files.
This gives an interface to underlying layers of the storage stack which
can copy without reading and writing all the data. There are a few
On Feb 20, 2015, at 1:50 AM, Michael Kerrisk mtk.manpa...@gmail.com 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
On Dec 2, 2014, at 12:23 PM, Theodore Ts'o ty...@mit.edu wrote:
On Tue, Dec 02, 2014 at 07:55:48PM +0200, Boaz Harrosh wrote:
This I do not understand. I thought that I_DIRTY_TIME, and the all
lazytime mount option, is only for atime. So if there are dirty
pages then there are also m/ctime
On Nov 26, 2014, at 3:48 PM, Dave Chinner da...@fromorbit.com wrote:
On Wed, Nov 26, 2014 at 05:23:56AM -0500, Theodore Ts'o wrote:
Add an optimization for the MS_LAZYTIME mount option so that we will
opportunistically write out any inodes with the I_DIRTY_TIME flag set
in a particular inode
On Nov 21, 2014, at 1:59 PM, Theodore Ts'o ty...@mit.edu wrote:
Guarantee that the on-disk timestamps will be no more than 24 hours
stale.
Signed-off-by: Theodore Ts'o ty...@mit.edu
---
fs/fs-writeback.c | 1 +
fs/inode.c | 7 ++-
include/linux/fs.h | 1 +
3 files changed, 8
On Jul 30, 2014, at 11:18 AM, David Sterba dste...@suse.cz wrote:
Add a new member to fiemap_extent that represents the physical extent
length. This value is undefined if the flag EXTENT_PHYS_LENGTH is not
set.
The description here of PHYS_LENGTH makes sense...
The patch description should
On Jul 24, 2014, at 1:22 PM, David Sterba dste...@suse.cz wrote:
On Thu, Jul 17, 2014 at 12:07:57AM -0600, Andreas Dilger wrote:
any progress on this patch series?
I'm sorry I got distracted at the end of year and did not finish the
series.
I never saw an updated version of this patch
. It should be fine to use:
#define FIEMAP_EXTENT_PHYS_LENGTH 0x0010
since this flag was never used.
Cheers, Andreas
On Dec 12, 2013, at 5:02 PM, Andreas Dilger adil...@dilger.ca wrote:
On Dec 12, 2013, at 4:24 PM, Dave Chinner da...@fromorbit.com wrote:
On Thu, Dec 12, 2013 at 04:25
On Dec 12, 2013, at 8:26 AM, David Sterba dste...@suse.cz wrote:
Set the EXTENT_DATA_COMPRESSED flag together with EXTENT_ENCODED as
defined by fiemap spec.
Signed-off-by: David Sterba dste...@suse.cz
---
fs/btrfs/extent_io.c |9 +++--
1 files changed, 7 insertions(+), 2
series looks good to me (one minor nit if it needs to be resubmitted
for some reason). You can add my:
Reviewed-by: Andreas Dilger adil...@dilger.ca
V3:
Based on feedback from Andreas, implement #1 from V2, current users of
fiemap_fill_next_extent (fs/, ext4, gfs2, ocfs2, nilfs2, xfs) updated
On Dec 12, 2013, at 4:24 PM, Dave Chinner da...@fromorbit.com wrote:
On Thu, Dec 12, 2013 at 04:25:59PM +0100, David Sterba wrote:
This flag was not accepted when fiemap was proposed [2] due to lack of
in-kernel users. Btrfs has compression for a long time and we'd like to
see that an extent
On 2012-05-25, at 9:59, Alexander Block abloc...@googlemail.com wrote:
On Fri, May 25, 2012 at 5:42 PM, Josef Bacik jo...@redhat.com wrote:
On Fri, May 25, 2012 at 05:35:37PM +0200, Alexander Block wrote:
Hello,
(this is a resend with proper CC for linux-fsdevel and linux-kernel)
I would
On 2012-04-16, at 9:13 AM, Jan Kara wrote:
Another potential contention point might be patch 19. In that patch
we make freeze_super() refuse to freeze the filesystem when there
are open but unlinked files which may be impractical in some cases.
The main reason for this is the problem with
On 2012-04-16, at 5:43 PM, Dave Chinner wrote:
On Mon, Apr 16, 2012 at 03:02:50PM -0700, Andreas Dilger wrote:
On 2012-04-16, at 9:13 AM, Jan Kara wrote:
Another potential contention point might be patch 19. In that patch
we make freeze_super() refuse to freeze the filesystem when
On 2012-03-09, at 9:48 PM, Ted Ts'o wrote:
On Fri, Mar 09, 2012 at 04:09:43PM -0800, Andreas Dilger wrote:
Just reading this on the plane, so I can't find the exact reference
that I want, but a solution to this problem with htree was discussed
a few years ago between myself and Coly Li
On 2011-09-17, at 12:10 AM, Jeff Liu jeff@oracle.com wrote:
I once posted a similar patch for this issue which can be found at:
http://www.spinics.net/lists/linux-btrfs/msg12169.html
with an additional improvement if the offset is larger or equal to the
file size, return -ENXIO in
On 2011-08-25, at 12:40 AM, Dave Chinner wrote:
On Thu, Aug 25, 2011 at 02:06:32AM -0400, Christoph Hellwig wrote:
On Tue, Jun 28, 2011 at 11:33:19AM -0400, Josef Bacik wrote:
This is a test to make sure seek_data/seek_hole is acting like it does on
Solaris. It will check to see if the fs
On 2011-06-27, at 12:02 PM, Josef Bacik wrote:
This is a test to make sure seek_data/seek_hole is acting like it does on
Solaris. It will check to see if the fs supports finding a hole or not and
will
adjust as necessary.
diff --git a/src/seek-tester.c b/src/seek-tester.c
new file mode
On May 26, 2011, at 14:03, Andi Kleen wrote:
On Thu, May 26, 2011 at 03:02:42PM -0400, Josef Bacik wrote:
+/*
+ * If this dentry needs lookup, don't set the referenced flag so that it
+ * is more likely to be cleaned up by the dcache shrinker in case of
+ * memory pressure.
+
On May 23, 2011, at 15:43, Josef Bacik wrote:
This just gets us ready to support the SEEK_HOLE and SEEK_DATA flags. Turns
out
using fiemap in things like cp cause more problems than it solves, so lets try
and give userspace an interface that doesn't suck. We need to match solaris
here, and
On 2011-05-20, at 2:07 PM, Andi Kleen a...@firstfloor.org wrote:
Josef Bacik jo...@redhat.com writes:
Btrfs (and I'd venture most other fs's) stores its indexes in nice disk order
for readdir, but unfortunately in the case of anything that stats the files
in
order that readdir spits back
On May 19, 2011, at 11:58, Josef Bacik wrote:
Btrfs (and I'd venture most other fs's) stores its indexes in nice disk order
for readdir, but unfortunately in the case of anything that stats the files in
order that readdir spits back (like oh say ls) that means we still have to do
the normal
On May 5, 2011, at 12:10, Matthew Wilcox wrote:
On Wed, May 04, 2011 at 08:51:39AM -0600, Andreas Dilger wrote:
I was aware of REQ_META, but I didn't know there was any benefit to
using it. I think it would be easy to set REQ_META on all ext4 metadata
if there was a reason to do so.
The CFQ
On 2011-05-04, at 5:45 AM, Gao, Yunpeng yunpeng@intel.com wrote:
Yes, I have been working on some changes that allow us to tag bios and
pass the information out to storage. These patches have been on the back
burner for a while due to other commitments. But I'll dig them out and
post them
On 2011-04-22, at 11:08 AM, Sunil Mushran sunil.mush...@oracle.com wrote:
On 04/22/2011 10:03 AM, Eric Blake wrote:
cp can read whatever blocksize it chooses. If that block contains
zero, it would signal cp that maybe it should SEEK_DATA and skip
reading all those blocks. That's all. We are
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 /* Extents */
#define FS_DIRECTIO_FL 0x0010 /* Use direct i/o */
+#define FS_NOCOW_FL 0x0080 /* Do not cow file */
On 2011-02-24, at 2:40 AM, liubo wrote:
#define FS_DIRECTIO_FL 0x0010 /* Use direct i/o */
+#define FS_NOCOW_FL 0x0020 /* Do not cow file */
+#define FS_COW_FL0x0010 /* Cow file */
#define FS_RESERVED_FL
On 2010-12-28, at 09:06, Marco Stornelli wrote:
it seems that ext4/btrfs code for fallocate doesn't check for
immutable/append inode flag.
fallocate() probably shouldn't be allowed for immutable files, but it makes a
lot of sense to call fallocate() on append-only files to avoid fragmentation,
On 2010-12-07, at 10:02, Trond Myklebust wrote:
On Tue, 2010-12-07 at 17:51 +0100, Christoph Hellwig wrote:
It's just as stable as a real dev_t in the times of hotplug and udev.
As long as you don't touch anything including not upgrading the kernel
it's remain stable, otherwise it will break.
On 2010-12-06, at 09:48, J. Bruce Fields wrote:
On Fri, Dec 03, 2010 at 04:01:44PM -0700, Andreas Dilger wrote:
Any chance we can add a -get_fsid(sb, inode) method to
export_operations (or something simiar), that allows the filesystem to
generate an FSID based on the volume and inode
On 2010-12-08, at 16:07, Neil Brown wrote:
On Mon, 6 Dec 2010 11:48:45 -0500 J. Bruce Fields bfie...@redhat.com
wrote:
On Fri, Dec 03, 2010 at 04:01:44PM -0700, Andreas Dilger wrote:
Any chance we can add a -get_fsid(sb, inode) method to
export_operations (or something simiar), that allows
On 2010-12-03, at 15:45, J. Bruce Fields wrote:
We're using statfs64.fs_fsid for this; I believe that's both stable
across reboots and distinguishes between subvolumes, so that's OK.
(That said, since fs_fsid doesn't work for other filesystems, we depend
on an explicit check for a filesystem
On 2010-11-16, at 20:11, Dave Chinner wrote:
On Tue, Nov 16, 2010 at 06:22:47PM -0600, Andreas Dilger wrote:
IMHO, it makes more sense for consistency and get what users
expect that these be treated as flags. Some users will want
KEEP_SIZE, but in other cases it may make sense that a hole
On 2010-11-16, at 20:34, Josef Bacik wrote:
FWIW I agree with Dave, the only question at this point is do we force users
to specify KEEP_SIZE with PUNCH_HOLE? On one hand it makes the interface a
bit more consistent, on the other hand it makes the documentation a little
weird
We have
On 2010-11-16, at 07:14, Jan Kara wrote:
Yeah I went back and forth on this. KEEP_SIZE won't change the behavior of
PUNCH_HOLE since PUNCH_HOLE implicitly means keep the size. I figured since
its mode and not flags it would be ok to make either way accepted, but
if you prefer PUNCH_HOLE
On 2010-09-03, at 05:03, Florian Weimer wrote:
* Miao Xie:
EXPORT_SYMBOL(memcpy);
I think you need to change that to EXPORT_SYMBOL_GPL, because the code
is now licensed under the GPL, and not the GPL plus kernel exceptions
(whatever they are, but they undoubtly exist), unlike the
)? Disallowing cleancache
on a filesystem that uses 64-bit (or larger) inodes on a 32-bit system reduces
its usefulness.
Cheers, Andreas
--
Andreas Dilger
Lustre Technical Lead
Oracle Corporation Canada Inc.
--
To unsubscribe from this list: send the line unsubscribe linux-btrfs in
the body of a message
in btrfs and/or a revived compressed ext4.
That would mean that the on-disk compression algorithm needs to match the
in-memory algorithm, which implies that the in-memory compression algorithm
should be selectable on a per-mapping basis.
Cheers, Andreas
--
Andreas Dilger
Lustre Technical Lead
Oracle
the minimal changes being done to ext3/ext4, I don't have any objection
to this. Being able to hook ext4 into SSDs for hierarchical caching is
something that will become increasingly important for huge ext4 filesystems.
Acked-by: Andreas Dilger adil...@sun.com
Diffstat:
super.c
replaced by kdump and it
appears to be less usable IMHO.
Cheers, Andreas
--
Andreas Dilger
Sr. Staff Engineer, Lustre Group
Sun Microsystems of Canada, Inc.
--
To unsubscribe from this list: send the line unsubscribe linux-btrfs in
the body of a message to majord...@vger.kernel.org
More majordomo
adding named block devices
on the mount command line, which is already required for design 1) but
would have to be implemented additionally for design 2).
Cheers, Andreas
--
Andreas Dilger
Sr. Staff Engineer, Lustre Group
Sun Microsystems of Canada, Inc.
--
To unsubscribe from this list: send
of the devices to find
the remaining parts of the filesystem.
Cheers, Andreas
--
Andreas Dilger
Sr. Staff Engineer, Lustre Group
Sun Microsystems of Canada, Inc.
--
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
63 matches
Mail list logo