Re: cross-fs copy support

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

Re: [PATCH 10/10] Dynamic fault injection

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: >>> >>&

Re: [PATCH 10/10] Dynamic fault injection

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

Re: [PATCH 1/2] fs: hoist BTRFS_IOC_[SG]ET_FSLABEL to vfs

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

Re: [PATCH] mm: save/restore current->journal_info in handle_mm_fault

[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

Re: Ideas to reuse filesystem's checksum to enhance dm-raid1/10/5/6?

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

Re: [PATCH] ioctl_getfsmap.2: document the GETFSMAP ioctl

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

Re: [PATCH 8/8] Revert "ext4: fix wrong gfp type under transaction"

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

Re: [LSF/MM TOPIC] sharing pages between mappings

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

Re: [PATCH] f2fs: support multiple devices

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

Re: [PATCH 5/5] don't set *REFERENCED unless we are on the lru list

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

Re: [Bug-tar] stat() on btrfs reports the st_blocks with delay (data loss in archivers)

> 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' >>>

Re: [Bug-tar] stat() on btrfs reports the st_blocks with delay (data loss in archivers)

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

Re: [PATCH 1.1/2] xfs: abstract PF_FSTRANS to PF_MEMALLOC_NOFS

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.

Re: fallocate mode flag for "unshare blocks"?

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

Re: fallocate mode flag for "unshare blocks"?

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

Re: [PATCH v7 0/4] VFS: In-kernel copy system call

> 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

Re: [PATCH v6 5/4] copy_file_range.2: New page documenting copy_file_range()

> 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 >

Re: [PATCH v1 0/8] VFS: In-kernel copy system call

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

Re: [PATCH v1 9/8] copy_file_range.2: New page documenting copy_file_range()

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

Re: [RFC 0/8] Allow GFP_NOFS allocation to fail

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

Re: [PATCH RFC 1/3] vfs: add copy_file_range syscall and vfs helper

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

Re: Documenting MS_LAZYTIME

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

Re: [PATCH-v5 1/5] vfs: add support for a lazytime mount option

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

Re: [PATCH-v4 6/7] ext4: add support for a lazytime mount option

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

Re: [PATCH 3/4] vfs: don't let the dirty time inodes get more than a day stale

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

Re: [PATCH 2/6] fiemap: add fe_phys_length and EXTENT_PHYS_LENGTH flag

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

Re: [PATCH 2/4 v3] fiemap: add EXTENT_DATA_COMPRESSED flag

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

Re: [PATCH 2/4 v3] fiemap: add EXTENT_DATA_COMPRESSED flag

. 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

Re: [PATCH 3/4 v3] btrfs: set FIEMAP_EXTENT_DATA_COMPRESSED for compressed extents

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

Re: [PATCH 0/4 v3] fiemap: introduce EXTENT_DATA_COMPRESSED flag

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

Re: [PATCH 2/4 v3] fiemap: add EXTENT_DATA_COMPRESSED flag

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

Re: atime and filesystems with snapshots (especially Btrfs)

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

Re: [PATCH 00/19 v5] Fix filesystem freezing deadlocks

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

Re: [PATCH 00/19 v5] Fix filesystem freezing deadlocks

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

Re: getdents - ext4 vs btrfs performance

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

Re: [PATCH 1/7] BTRFS: Fix lseek return value for error

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

Re: [PATCH] xfstests 255: add a seek_data/seek_hole tester

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

Re: [PATCH] xfstests 255: add a seek_data/seek_hole tester

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

Re: [PATCH 2/2] Btrfs: load the key from the dir item in readdir into a fake dentry

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. +

Re: [PATCH 1/3] fs: add SEEK_HOLE and SEEK_DATA flags V4

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

Re: [PATCH 1/2] fs: add a DCACHE_NEED_LOOKUP flag for d_flags

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

Re: [PATCH 1/2] fs: add a DCACHE_NEED_LOOKUP flag for d_flags

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

Re: Is it possible for the ext4/btrfs file system to pass some context related info to low level block driver?

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

Re: Is it possible for the ext4/btrfs file system to pass some context related info to low level block driver?

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

Re: [PATCH 1/2] fs: add SEEK_HOLE and SEEK_DATA flags

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

Re: [PATCH 1/2] Btrfs: add datacow flag in inode flag

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 */

Re: [RFC PATCH] Btrfs: add ioctl to set compress or cow per file/dir

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

Re: Bug in ext4/btrfs fallocate?

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,

Re: What to do about subvolumes?

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.

Re: What to do about subvolumes?

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

Re: What to do about subvolumes?

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

Re: What to do about subvolumes?

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

Re: [PATCH 1/6] fs: add hole punching to fallocate

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

Re: [PATCH 1/6] fs: add hole punching to fallocate

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

Re: [PATCH 1/6] fs: add hole punching to fallocate

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

Re: [PATCH 2/3] lib: improve the performance of memcpy and memmove of the general version

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

Re: [PATCH V3 0/8] Cleancache: overview

)? 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

Re: [PATCH V2 0/7] Cleancache (was Transcendent Memory): overview

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

Re: Cleancache [PATCH 6/7] (was Transcendent Memory): ext4 hook

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

Re: source line numbers with x86_64 modules? [Was: Re: [patch] measurements, numbers about CONFIG_OPTIMIZE_INLINING=y impact]

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

Re: Notes on support for multiple devices for a single filesystem

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

Re: Btrfs trees for linux-next

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