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 don't
>> need to keep
On 2012-03-09, at 3:29, Lukas Czerner wrote:
>
> I have created a simple script which creates a bunch of files with
> random names in the directory and then performs operation like list,
> tar, find, copy and remove. I have run it for ext4, xfs and btrfs with
> the 4k size files. And the result i
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
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 h
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
On Feb 14, 2019, at 11:59 PM, Omar Sandoval wrote:
>
> On Fri, Feb 15, 2019 at 11:16:57AM +1100, Dave Chinner wrote:
>> On Thu, Feb 14, 2019 at 03:14:29PM -0800, Omar Sandoval wrote:
>>> I see a few options, none of which are particularly nice:
>>>
>>> 1. Filesystems like XFS could choose not to
On Jun 25, 2019, at 12:03 PM, Darrick J. Wong wrote:
>
> On Tue, Jun 25, 2019 at 03:36:31AM -0700, Christoph Hellwig wrote:
>> On Fri, Jun 21, 2019 at 04:56:50PM -0700, Darrick J. Wong wrote:
>>> Hi all,
>>>
>>> The chattr(1) manpage has this to say about the immutable bit that
>>> system admini
[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 handle kernel NULL pointer derefer
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 "cross-subvolume
On Sep 20, 2018, at 10:40 PM, Zygo Blaxell
wrote:
>
> On Fri, Sep 21, 2018 at 12:59:31PM +1000, Dave Chinner wrote:
>> On Wed, Sep 19, 2018 at 12:12:03AM -0400, Zygo Blaxell wrote:
> [...]
>> With no DMAPI in the future, people with custom HSM-like interfaces
>> based on dmapi are starting to tu
On Feb 17, 2019, at 8:35 AM, Boaz Harrosh wrote:
>
> On 15/02/19 00:06, Dave Chinner wrote:
>> On Thu, Feb 14, 2019 at 02:00:07AM -0800, Omar Sandoval wrote:
>>> From: Omar Sandoval
>>>
>>> Hi,
>>>
>>> Since statx was added in 4.11, userspace has had an interface for
>>> reading btime (file cr
> On Feb 22, 2019, at 11:00 AM, Omar Sandoval wrote:
>
> On Tue, Feb 19, 2019 at 09:18:20AM +1100, Dave Chinner wrote:
>> On Sat, Feb 16, 2019 at 06:57:45PM -0700, Andreas Dilger wrote:
>>> While it may be a bit of a stretch to call this "forensic evidence",
27;, 31, struct fsxattr)
>> +#define 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 o
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
cover letter is not saved, but the commit stays around
On May 18, 2018, at 1:10 PM, Kent Overstreet wrote:
>
> On Fri, May 18, 2018 at 01:05:20PM -0600, Andreas Dilger wrote:
>> On May 18, 2018, at 1:49 AM, Kent Overstreet
>> wrote:
>>>
>>> Signed-off-by: Kent Overstreet
>>
>> I agree with Chri
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 modify block
> alloca
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 mappings between
> f
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 ref counting is
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 shared extent may hit enos
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 30, 2016 at 11:27:55AM -0
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. Let's start by giving the flag a
> more
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 wrote:
>>> Theodore Ts'o
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 Brown in a while, so I volunteer
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 some kind of "copy accele
> 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
> server-side-copy (in the case of NF
> 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 -EBADF;
>
> Isn't 'f_op' a
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 metadata, and even some (btrf
On Apr 10, 2015, at 4:00 PM, Zach Brown 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
> candidates tha
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 th
On 2012-05-25, at 9:59, Alexander Block wrote:
> On Fri, May 25, 2012 at 5:42 PM, Josef Bacik 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 like to start a discu
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 --> then
> tar consid
> 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'
>>> Size: 2793472 Blocks: 5456 IO Block: 512regula
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 P
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
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 h
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 filesy
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
On 2010-12-08, at 10:27, J. Bruce Fields wrote:
> On Wed, Dec 08, 2010 at 10:16:29AM -0700, Andreas Dilger wrote:
>> It looks like mk_fsid() is only actually using the UUID if it is specified
>> in the /etc/exports file (AFAICS, this depends on ex_uuid being set from a
>&
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
On 2010-12-08, at 16:07, Neil Brown wrote:
> On Mon, 6 Dec 2010 11:48:45 -0500 "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_ope
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 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 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 fil
On 2011-04-22, at 11:08 AM, Sunil Mushran 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 not trying to ach
On 2011-05-04, at 5:45 AM, "Gao, Yunpeng" 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 later. We ju
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 t
On Dec 12, 2013, at 8:26 AM, David Sterba wrote:
> Set the EXTENT_DATA_COMPRESSED flag together with EXTENT_ENCODED as
> defined by fiemap spec.
>
> Signed-off-by: David Sterba
> ---
> fs/btrfs/extent_io.c |9 +++--
> 1 files changed, 7 insertions(+), 2 deletions(-)
>
> diff --git a/fs/b
e already.
The whole 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
> V3:
> Based on feedback from Andreas, implement #1 from V2, current users of
> fiemap_fill_next_extent (fs/, ext4, gfs2, oc
On Dec 12, 2013, at 4:24 PM, Dave Chinner 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 is compressed
flags. 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 wrote:
> On Dec 12, 2013, at 4:24 PM, Dave Chinner wrote:
>> On Thu, Dec 12, 2013 at 04:25:59PM +0100, Davi
On Jul 24, 2014, at 1:22 PM, David Sterba 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 upda
On Jul 30, 2014, at 11:18 AM, David Sterba 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 also mention t
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 2011-05-20, at 2:07 PM, Andi Kleen wrote:
> Josef Bacik 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 (like oh say ls) that mean
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,
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 pres
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
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 th
On 2011-09-17, at 12:10 AM, Jeff Liu 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 directly:
>
>
On Feb 20, 2015, at 1: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 piec
y the rest 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...@vge
of layering. With ZFS there is a distinct layer
that is handling the allocation, redundancy, and transactions (SPA, DMU)
that is exporting an object interface, and the filesystem (ZPL, or future
versions of Lustre) is built on top of that object interface.
Cheers, Andreas
--
Andreas Dilger
Sr. S
I
have enough grief with just initrd not having the right kernel module,
I'd hate to depend on tools to do the device assembly for the root fs.
> Advantages:keeps state in the kernel instead of in libraries
> Disadvantages: requires and additional user interface to mount
sing that for a few years, but it got 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 m
On Nov 21, 2014, at 1:59 PM, Theodore Ts'o wrote:
> Guarantee that the on-disk timestamps will be no more than 24 hours
> stale.
>
> Signed-off-by: Theodore Ts'o
> ---
> fs/fs-writeback.c | 1 +
> fs/inode.c | 7 ++-
> include/linux/fs.h | 1 +
> 3 files changed, 8 insertions(+), 1 del
On Nov 26, 2014, at 3:48 PM, Dave Chinner 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 table block
On Dec 2, 2014, at 12:23 PM, Theodore Ts'o 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 that c
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
> Diffstat:
> super.c
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 Corporation 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 at http://vger.kernel.org/majordomo-info.html
ke the NFS file handle)? 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 li
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
71 matches
Mail list logo
