On Fri, Feb 15, 2008 at 08:51:15PM +0900, Takashi Sato wrote:
> So XFS_IOC_FREEZE and XFS_IOC_THAW cannot be lifted to generic code simply.
> I think we should create new generic numbers for freeze and thaw
Actually we've lifted specific ioctls to the generic layer before all
the time in drivers.
On Sun, Feb 10, 2008 at 07:54:32AM -0500, Theodore Tso wrote:
> No, none of this is shared with e2fsprogs; e2fsprogs stopped using the
> kernel header files about seven years ago. (May 2001, e2fsprogs 1.20).
Yeah, I know userspace stopped using the direct copy. But for example
XFS has exact copie
On Sat, Feb 09, 2008 at 10:39:33AM +0100, Christoph Hellwig wrote:
> Move ext4 headers out of include/linux. This is just the trivial move,
> there's some more thing that could be done later.
>
> Ted, is anything of these shared with e2fsprogs or can we rip out all
> that #i
On Fri, Feb 08, 2008 at 08:26:57AM -0500, Andreas Dilger wrote:
> You may as well make the common ioctl the same as the XFS version,
> both by number and parameters, so that applications which already
> understand the XFS ioctl will work on other filesystems.
Yes. In facy you should be able to li
On Mon, Feb 04, 2008 at 02:35:29PM -0800, Andrew Morton wrote:
> On Mon, 4 Feb 2008 15:24:18 -0500
> Christoph Hellwig <[EMAIL PROTECTED]> wrote:
>
> > On Sun, Feb 03, 2008 at 07:15:40PM -0800, Andrew Morton wrote:
> > > On Sun, 3 Feb 2008 20:36:26 -0500 Theodore
On Sun, Feb 03, 2008 at 07:15:40PM -0800, Andrew Morton wrote:
> On Sun, 3 Feb 2008 20:36:26 -0500 Theodore Tso <[EMAIL PROTECTED]> wrote:
>
> > On Sun, Feb 03, 2008 at 12:25:51PM -0800, Andrew Morton wrote:
> > > When I merge David's iget coversion patches this will instead wreck the
> > > ext4 p
On Fri, Jan 25, 2008 at 09:42:30PM +0900, Takashi Sato wrote:
> Hi,
>
> >I am also wondering whether we should have system call(s) for these:
> >
> >On Jan 25, 2008 12:59 PM, Takashi Sato <[EMAIL PROTECTED]> wrote:
> >>+ case EXT3_IOC_FREEZE: {
> >
> >>+ case EXT3_IOC_THAW: {
> >
> >An
On Tue, Jan 15, 2008 at 01:15:33PM +, Christoph Hellwig wrote:
> They won't fsck in planned downtimes. They will have to use fsck when
> the shit hits the fan and they need to. Not sure about ext3, but big
> XFS user with a close tie to the US goverment were concerned about t
On Tue, Jan 15, 2008 at 03:04:41AM -0800, Andrew Morton wrote:
> I'm wondering about the real value of this change, really.
>
> In any decent environment, people will fsck their ext3 filesystems during
> planned downtime, and the benefit of reducing that downtime from 6
> hours/machine to 2 hours/
On Thu, Oct 04, 2007 at 01:50:36AM -0400, Theodore Ts'o wrote:
> From: Mingming Cao <[EMAIL PROTECTED]>
>
> JBD: Replace slab allocations with page cache allocations
It's page allocations, not page cache allocations.
> Also this patch cleans up jbd_kmalloc and replace it with kmalloc directly
T
On Wed, Sep 26, 2007 at 06:59:46AM -0400, Theodore Tso wrote:
> It looks like you pulled fsck from the master branch of e2fsprogs git;
> there is one slight bug fix in the maint branch that hasn't been
> merged into master yet, commit ed773a263829493e4e4bf612dbec2380cf09349f:
I'll pick that up.
>
On Tue, Sep 25, 2007 at 10:25:50PM +0200, Kay Sievers wrote:
> > Technical details :-)
>
> What do you miss, these are all technical details. :) In simple words,
> we need a completely policy-free, not try-to-be-smart in any sense set
> of functions to identify a bytestream by magic bytes.
Which
those libs is still ongoing and I haven't read up on the fsprobe library
either.
Signed-off-by: Christoph Hellwig <[EMAIL PROTECTED]>
Index: util-linux-ng/Makefile.am
===
--- util-linux-ng.orig/Makefile.am 2007-09-25 17
On Mon, Sep 17, 2007 at 03:57:31PM -0700, Mingming Cao wrote:
> Here is the incremental small cleanup patch.
>
> Remove kamlloc usages in jbd/jbd2 and consistently use
> jbd_kmalloc/jbd2_malloc.
Shouldn't we kill jbd_kmalloc instead?
-
To unsubscribe from this list: send the line "unsubscribe
On Mon, Sep 17, 2007 at 12:29:51PM -0700, Mingming Cao wrote:
> The problem with this patch, as Andreas Dilger pointed today in ext4
> interlock call, for 1k,2k block size ext2/3/4, get_free_pages() waste
> 1/3-1/2 page space.
>
> What was the originally intention to set up slabs for committed_da
On Mon, Sep 03, 2007 at 12:31:49PM -0700, Christoph Lameter wrote:
> So you'd be fine with replacing the allocs with
>
> get_free_pages(GFP_xxx, get_order(size)) ?
Yes. And rip out all that code related to setting up the slabs. I plan
to add WARN_ONs to bio_add_page and friends to detect furthe
On Mon, Sep 03, 2007 at 12:55:04AM -0700, Christoph Lameter wrote:
> On Sun, 2 Sep 2007, Christoph Hellwig wrote:
>
> > > We are doing what you describe right now. So the current code is broken?
> > Yes.
>
> How about getting rid of the slabs there and use kmalloc? Kma
On Sun, Sep 02, 2007 at 04:40:21AM -0700, Christoph Lameter wrote:
> On Sat, 1 Sep 2007, Christoph Hellwig wrote:
>
> > On Fri, Aug 31, 2007 at 05:12:18PM -0700, Mingming Cao wrote:
> > > >From clameter:
> > > Teach jbd/jbd2 slab management to support >8k
On Fri, Aug 31, 2007 at 05:12:18PM -0700, Mingming Cao wrote:
> >From clameter:
> Teach jbd/jbd2 slab management to support >8k block size. Without this, it
> refused to mount on >8k ext3.
But the real fix is to kill this code. We can't send down slab pages
down the block layer without breaking
On Thu, Aug 30, 2007 at 05:07:46PM +1000, Nathan Scott wrote:
> To improve metadata performance, you have many options with XFS (which
> ones are useful depends on the type of metadata workload) - you can try
> a v2 format log, and mount with "-o logbsize=256k", try increasing the
> directory block
On Fri, Aug 10, 2007 at 04:47:52PM -0400, Jeff Layton wrote:
> attr->ia_valid after the setattr operation returns. If either ATTR_KILL_*
> bit is set then BUG(). The helper function already clears those bits
> so anything using it should automatically be ok. We'd have to fix
> up NFS and a few othe
> +void attr_kill_to_mode(struct inode *inode, struct iattr *attr)
This function badly needs a kerneldoc description. Also I can't say
I like the name a lot, but without a clearly better idea I should
probably not complain :)
We should at least add a generic_ prefix to indicate it's a generic
he
First thanks a lot for doing this work, it's been long needed.
Second please don't send out that many patches. We encourage people
to split things into small patches when the changes are logially
separated. Which these are not - it's a flag day change (which btw
is fine despite the rants soe peo
On Sun, Jul 29, 2007 at 11:30:36AM -0600, Andreas Dilger wrote:
> Sigh, we HAVE a patch that was only adding delalloc to ext4, but it
> was rejected because "that functionality should go into the VFS".
> Since the performance improvement of delalloc is quite large, we'd
> like to get this into the
On Sun, Jul 29, 2007 at 09:48:10PM +0400, Alex Tomas wrote:
> I think the latter one is better because it supports bs < pagesize
> (though I'm not sure about data=ordered yet). I'm not against putting
> most of the patch into fs/ext4/, but at least few bits to be changed
> in fs/ - exports in fs/m
On Fri, Jul 27, 2007 at 04:38:44PM +0400, Alex Tomas wrote:
> I just realized that you're talking about data=ordered mode in ext4,
> where care is taken to prevent on-disk references to no-yet-written
> blocks.
Any reference to non-written blocks is a bug.
-
To unsubscribe from this list: send th
On Fri, Jul 27, 2007 at 11:51:56AM +0400, Alex Tomas wrote:
> >Secondly, apart from delalloc, XFS cannot use the generic code paths
> >for writeback because unwritten extent conversion also requires
> >custom I/O completion handlers. Given that __mpage_writepage() only
> >calls ->writepage when it
On Fri, Jul 27, 2007 at 03:07:14PM +1000, David Chinner wrote:
> > It duplicates fs/mpage.c in bio building and introduces new generic API
> > (iomap, map_blocks_t, etc).
>
> Using a new API for new functionality is a bad thing?
Depends on wht you do. This patch is just a quickhack to shoe-horn
On Thu, Jul 26, 2007 at 06:32:56AM -0400, Jeff Garzik wrote:
> Is this based on Christoph's work?
>
> Christoph, or some other XFS hacker, already did generic delalloc,
> modeled on the XFS delalloc code.
This is not based on my attempt to make the xfs writeout path generic.
Alex's variant is a
On Fri, Jul 13, 2007 at 07:48:58PM +0530, Amit K. Arora wrote:
> Ok. Since we have only one flag (FALLOC_FL_KEEP_SIZE) and we do not want
> to declare the default mode (FALLOC_ALLOCATE), we can _just_ have this
> flag and remove the other mode too (FALLOC_RESV_SPACE).
> Is this what you are suggest
On Fri, Jul 13, 2007 at 06:18:47PM +0530, Amit K. Arora wrote:
> From: David P. Quigley <[EMAIL PROTECTED]>
>
> Revalidate the write permissions for fallocate(2), in case security policy has
> changed since the files were opened.
>
> Acked-by: James Morris <[EMAIL PROTECTED]>
> Signed-off-by: Dav
On Fri, Jul 13, 2007 at 06:17:55PM +0530, Amit K. Arora wrote:
> /*
> + * sys_fallocate - preallocate blocks or free preallocated blocks
> + * @fd: the file descriptor
> + * @mode: mode specifies the behavior of allocation.
> + * @offset: The offset within file, from where allocation is being
> +
On Wed, Jul 11, 2007 at 05:57:17AM -0600, Andreas Dilger wrote:
> Ah, this is the patch to disable i_version updates for Lustre. I don't
> think any normal user would use this mount option, so I don't know if
> there is a need to document it.
This is a reason to not merge it at all. If the only
On Wed, Jul 11, 2007 at 05:52:24AM -0600, Andreas Dilger wrote:
> On Jul 11, 2007 09:47 +0100, Christoph Hellwig wrote:
> > On Sun, Jul 01, 2007 at 03:37:45AM -0400, Mingming Cao wrote:
> > > This patch is on top of i_version_update_vfs.
> > > The i_version field o
On Wed, Jul 04, 2007 at 03:37:01PM +1000, Timothy Shimmin wrote:
> We use this capability in XFS at the moment.
> I think this is mainly for DMF (HSM) but is done via the xfs handle
> interface
> (xfs_open_by_handle) AFAICT.
>
You're not :) You're using an O_INVIBLE equivalent (as described bel
On Mon, Jul 02, 2007 at 08:55:43AM +1000, David Chinner wrote:
> Given the current behaviour for posix_fallocate() in glibc, I think
> that retaining the same error semantic and punting the cleanup to
> userspace (where the app will fail with ENOSPC anyway) is the only
> sane thing we can do here.
On Tue, Jul 03, 2007 at 05:16:50PM +0530, Amit K. Arora wrote:
> Well, if you see the modes proposed using above flags :
>
> #define FA_ALLOCATE 0
> #define FA_DEALLOCATE FA_FL_DEALLOC
> #define FA_RESV_SPACE FA_FL_KEEP_SIZE
> #define FA_UNRESV_SPACE (FA_FL_DEALLOC | FA_FL_KEEP_SIZE |
> F
On Sun, Jul 01, 2007 at 03:37:45AM -0400, Mingming Cao wrote:
> This patch is on top of i_version_update_vfs.
> The i_version field of the inode is set on inode creation and incremented when
> the inode is being modified.
Which is not what i_version is supposed to do. It'll get you tons of misses
On Tue, Jul 03, 2007 at 03:38:48PM +0530, Amit K. Arora wrote:
> > FA_FL_DEALLOC 0x01 /* deallocate unwritten extent (default
> > allocate) */
> > FA_FL_KEEP_SIZE 0x02 /* keep size for EOF {pre,de}alloc (default change
> > size) */
> > FA_FL_DEL_DATA 0x04 /* delete existing
On Wed, Jun 27, 2007 at 11:36:57PM +1000, David Chinner wrote:
> > This
> > would seem to be the only impediment from using fallocated files
> > for swap files. Maybe if FIEMAP was used by mkswap to get an
> > "UNWRITTEN" flag back instead of "HOLE" it wouldn't be a problem.
>
> Probably. If we t
On Tue, Jun 26, 2007 at 04:02:47PM +0530, Amit K. Arora wrote:
> > Can you clarify - what is the current behaviour when ENOSPC (or some other
> > error) is hit? Does it keep the current fallocate() or does it free it?
>
> Currently it is left on the file system implementation. In ext4, we do
> no
On Thu, Jun 14, 2007 at 03:14:58AM -0600, Andreas Dilger wrote:
> I suppose it might be a bit late in the game to add a "goal"
> parameter and e.g. FA_FL_REQUIRE_GOAL, FA_FL_NEAR_GOAL, etc to make
> the API more suitable for XFS? The goal could be a single __u64, or
> a struct with e.g. __u64 byte
On Thu, Jun 28, 2007 at 11:33:42AM -0700, Andrew Morton wrote:
> I think Mingming was asking that Ted move the current quilt tree into git,
> presumably because she's working off git.
>
> I'm not sure what to do, really. The core kernel patches need to be in
> Ted's tree for testing but that'll c
On Fri, Jun 15, 2007 at 08:21:09AM +1000, David Chinner wrote:
> Yeah, it can run a subset of the tests on NFS and UDF filesystems as well and
> there are some specific UDF-only tests in it too. I think the NFS test group
> is mostly generic tests that don't use or test specific XFS features.
Act
On Wed, Jun 13, 2007 at 05:57:59PM +0400, Dmitriy Monakhov wrote:
> Function prerform check for signgle region, with out respect to
> segment nature of iovec, For example writev no longer works :)
Btw, could someone please start to collect all sniplets like this in
a nice simple regres
On Tue, Jun 05, 2007 at 10:11:12AM +0400, Vasily Averin wrote:
> >>return d_splice_alias(inode, dentry);
> >> }
> > Seems reasonable. So this prevents the bad inodes from getting onto the
> > orphan list in the first place?
>
> make_bad_inode() is called from ext3_read_inode() that is called
On Mon, Apr 16, 2007 at 03:10:42PM +0400, Pavel Emelianov wrote:
> Christoph Hellwig wrote:
> > On Mon, Apr 16, 2007 at 11:41:14AM +0400, Pavel Emelianov wrote:
> >> If the thread failed to create the subsequent wait_event
> >> will hang forever.
> >>
> >
On Mon, Apr 16, 2007 at 11:41:14AM +0400, Pavel Emelianov wrote:
> If the thread failed to create the subsequent wait_event
> will hang forever.
>
> This is likely to happen if kernel hits max_threads limit.
>
> Will be critical for virtualization systems that limit the
> number of tasks and kern
On Thu, Apr 12, 2007 at 05:05:50AM -0600, Andreas Dilger wrote:
> struct fibmap_extent {
> __u64 fe_start; /* starting offset in bytes */
> __u64 fe_len; /* length in bytes */
> }
>
> struct fibmap {
> struct fibmap_extent fm_start; /* offset, l
On Tue, Mar 06, 2007 at 06:36:09AM -0800, Ulrich Drepper wrote:
> Christoph Hellwig wrote:
> > fallocate with the whence argument and flags is already quite complicated,
> > I'd rather have another call for placement decisions, that would
> > be called on an fd to do pl
On Mon, Mar 05, 2007 at 12:02:59PM -0800, Mingming Cao wrote:
> Yep, I think it makes sense to use preallocation for defragmentation.
> After all both preallocation and defragmentation shall call underlying
> filesystem multiple block allocator to try to allocate a chunk of
> contiguous blocks on
On Mon, Mar 05, 2007 at 07:15:33AM -0800, Ulrich Drepper wrote:
> Theodore Tso wrote:
> > Given that glibc already has to support this for older kernels, I
> > would argue that there's no point putting in generic support for
> > filesystem that can't support a more advanced way of doing things.
>
On Sat, Mar 03, 2007 at 11:45:32PM +0100, Arnd Bergmann wrote:
> > I'd be more happy to have the write out zeroes loop in glibc. ?And
> > glibc needs to have it anyway, for older kernels.
>
> A generic_fallocate makes sense to me iff we can do it in the kernel
> more significantly more efficiently
On Sun, Mar 04, 2007 at 08:11:17PM +, Anton Altaparmakov wrote:
> glibc cannot ever be smart enough because a file system driver will
> always know better and be able to do things in a much more optimized
> way.
Please read the thread again. That is not what anyone proposed.
The issues we
On Thu, Mar 01, 2007 at 05:29:15PM -0600, Eric Sandeen wrote:
> Amit K. Arora wrote:
>
> Might want more error checking in there, something like (rough cut)...
> (or is some of this glibc's job?)
Yeah, we need to have this checks. We can't rely on userspace not
passing arguments that might corru
On Thu, Mar 01, 2007 at 10:44:16PM +, Dave Kleikamp wrote:
> Would EINVAL (or whatever) make it back to the caller of
> posix_fallocate(), or would glibc fall back to its current
> implementation?
>
> Forgive me if I haven't put enough thought into it, but would it be
> useful to create a gene
On Fri, Mar 02, 2007 at 12:04:45AM +0530, Amit K. Arora wrote:
> This is to give a heads up on few patches that we will be soon coming up
> with. These patches implement a new system call sys_fallocate() and a
> new inode operation "fallocate", for persistent preallocation. The new
> system call, a
On Sat, Dec 23, 2006 at 02:31:23PM +1100, David Chinner wrote:
> > - ext4-delayed-allocation.patch
> >delayed allocation itself, enabled by "delalloc" mount option.
> >extents support is also required. currently it works only
> >with blocksize=pagesize.
>
> Ah, that's why you can get
On Mon, Oct 09, 2006 at 09:15:28PM -0500, Steve Lord wrote:
> Hi Dave,
>
> My recollection is that it used to default to on, it was disabled
> because it needs to map the buffer into a single contiguous chunk
> of kernel memory. This was placing a lot of pressure on the memory
> remapping code, so
59 matches
Mail list logo
