On Sat, Aug 04, 2007 at 09:16:35PM +0200, Florian Weimer wrote:
> * Andrew Morton:
>
> > The easy preventive is to mount with data=writeback. Maybe that should
> > have been the default.
>
> The documentation I could find suggests that this may lead to a
> security weakness (old data in blocks
On Sun, Aug 05, 2007 at 06:42:30AM -0400, Jeff Garzik wrote:
> Jakob Oestergaard wrote:
> >Oh dear.
> >
> >Why not just make ext3 fsync() a no-op while you're at it?
> >
> >Distros can turn it back on if it's needed...
> >
> >Of course I'm not serious, but like atime, fsync() is something one
>
>
On Sun, Aug 05, 2007 at 06:42:30AM -0400, Jeff Garzik wrote:
Jakob Oestergaard wrote:
Oh dear.
Why not just make ext3 fsync() a no-op while you're at it?
Distros can turn it back on if it's needed...
Of course I'm not serious, but like atime, fsync() is something one
No, they are
On Sat, Aug 04, 2007 at 09:16:35PM +0200, Florian Weimer wrote:
* Andrew Morton:
The easy preventive is to mount with data=writeback. Maybe that should
have been the default.
The documentation I could find suggests that this may lead to a
security weakness (old data in blocks of a file
On Sat, Aug 04, 2007 at 08:30:21PM +0200, Jesper Juhl wrote:
Back in 2006 (2006-10-31 to be specific, reposted on 2006-11-16), I
submitted a patch to fix a potential NULL pointer deref in XFS on
failed mount.
Already checked into xfs-dev tree. Will go to next mainline merge.
On Thu, Aug 02, 2007 at 03:06:15PM +0200, Peter Zijlstra wrote:
> On Thu, 2007-08-02 at 14:41 +0200, Petr Tesarik wrote:
> > Hello,
> >
> > while solving a different issue, my colleague Libor Pechacek found a
> > problem with handling mmapped sparse files. If you mmap the hole insidea
> > sparse
On Thu, Aug 02, 2007 at 03:06:15PM +0200, Peter Zijlstra wrote:
On Thu, 2007-08-02 at 14:41 +0200, Petr Tesarik wrote:
Hello,
while solving a different issue, my colleague Libor Pechacek found a
problem with handling mmapped sparse files. If you mmap the hole insidea
sparse file and
On Wed, Aug 01, 2007 at 10:45:16PM +0200, Miklos Szeredi wrote:
> The following strange behavior can be observed:
>
> 1. large file is written
> 2. after 30 seconds, nr_dirty goes down by 1024
> 3. then for some time (< 30 sec) nothing happens (disk idle)
> 4. then nr_dirty again goes down by
On Wed, Aug 01, 2007 at 10:45:16PM +0200, Miklos Szeredi wrote:
The following strange behavior can be observed:
1. large file is written
2. after 30 seconds, nr_dirty goes down by 1024
3. then for some time ( 30 sec) nothing happens (disk idle)
4. then nr_dirty again goes down by 1024
5.
[cc [EMAIL PROTECTED]
On Mon, Jul 30, 2007 at 12:10:52PM -0400, Ryan Bair wrote:
> Kernel: 2.6.18-4-amd64 (Debian 2.6.18.dfsg.1-12etch2) Debian Etch
> System: Dell PowerEdge 1850
> Processor: 3.2 GHz Intel Xeon w/ microcode v1.14a, Hyperthreading disabled.
> RAM: 2x1GB ECC DDR-400
> RAID
[cc [EMAIL PROTECTED]
On Mon, Jul 30, 2007 at 12:10:52PM -0400, Ryan Bair wrote:
Kernel: 2.6.18-4-amd64 (Debian 2.6.18.dfsg.1-12etch2) Debian Etch
System: Dell PowerEdge 1850
Processor: 3.2 GHz Intel Xeon w/ microcode v1.14a, Hyperthreading disabled.
RAM: 2x1GB ECC DDR-400
RAID Controller:
draft of the page back to me.
>
> Thanks for going through the manpage and improving it!
>
> My comments are below in between ... tags.
Does this Q really need to be encoded in nroff comments? ;)
> .\" FIXME Amit: I need author and license information for thi
and improving it!
My comments are below in between Amit ... /Amit tags.
Does this QA really need to be encoded in nroff comments? ;)
.\ FIXME Amit: I need author and license information for this page.
.\ Amit
.\David Chinner is the original author, hence he can help with this.
.\ /Amit
Patch
On Fri, Jul 20, 2007 at 07:40:04AM +0200, Nick Piggin wrote:
> Fix page index to offset conversion overflows in buffer layer, ecryptfs,
> and ocfs2.
>
> It would be nice to convert the whole tree to page_offset, but for now
> just fix the bugs.
Yup, that's part of the clean-ups in Christoph
On Fri, Jul 20, 2007 at 07:40:04AM +0200, Nick Piggin wrote:
Fix page index to offset conversion overflows in buffer layer, ecryptfs,
and ocfs2.
It would be nice to convert the whole tree to page_offset, but for now
just fix the bugs.
Yup, that's part of the clean-ups in Christoph Lameter's
tten region requires a node split, that could result
> in the allocation of new meta data which obviously could fail if the disk is
> truly full.
% git-log 84e1e99f112dead8f9ba036c02d24a9f5ce7f544 |head -10
commit 84e1e99f112dead8f9ba036c02d24a9f5ce7f544
Author: David Chinner <[EMAIL PRO
, that could result
in the allocation of new meta data which obviously could fail if the disk is
truly full.
% git-log 84e1e99f112dead8f9ba036c02d24a9f5ce7f544 |head -10
commit 84e1e99f112dead8f9ba036c02d24a9f5ce7f544
Author: David Chinner [EMAIL PROTECTED]
Date: Mon Jun 18 16:50:27 2007 +1000
FYI.
Initial support for fallocate-based pre-allocation in
xfs_io for testing. This currently only works on ia64 because
of the hard coded syscall number and will require autoconf
magic to conditionally compile in this support.
This allows simple command-line based testing of fallocate
based
Initial implementation of ->fallocate for XFS.
Version 2:
o Make allocation and setting the file size atomic.
o Drop deallocate/punch functionality
o use mode field appropriately to determine if size needs changing.
---
fs/xfs/linux-2.6/xfs_iops.c | 47
sys_fallocate for ia64. This uses the empty slot originally
reserved for move_pages.
Signed-Off-By: Dave Chinner <[EMAIL PROTECTED]>
---
arch/ia64/kernel/entry.S |2 +-
include/asm-ia64/unistd.h |2 +-
2 files changed, 2 insertions(+), 2 deletions(-)
Index:
On Fri, Jul 13, 2007 at 04:31:09PM +0200, Andrea Arcangeli wrote:
> On Fri, Jul 13, 2007 at 05:13:08PM +1000, David Chinner wrote:
> > Sure. Fundamentally, though, I think it is the wrong approach to
> > take - it's a workaround for a big negative side effect of
> >
On Fri, Jul 13, 2007 at 04:31:09PM +0200, Andrea Arcangeli wrote:
On Fri, Jul 13, 2007 at 05:13:08PM +1000, David Chinner wrote:
Sure. Fundamentally, though, I think it is the wrong approach to
take - it's a workaround for a big negative side effect of
increasing page size. It introduces
sys_fallocate for ia64. This uses the empty slot originally
reserved for move_pages.
Signed-Off-By: Dave Chinner [EMAIL PROTECTED]
---
arch/ia64/kernel/entry.S |2 +-
include/asm-ia64/unistd.h |2 +-
2 files changed, 2 insertions(+), 2 deletions(-)
Index:
Initial implementation of -fallocate for XFS.
Version 2:
o Make allocation and setting the file size atomic.
o Drop deallocate/punch functionality
o use mode field appropriately to determine if size needs changing.
---
fs/xfs/linux-2.6/xfs_iops.c | 47
FYI.
Initial support for fallocate-based pre-allocation in
xfs_io for testing. This currently only works on ia64 because
of the hard coded syscall number and will require autoconf
magic to conditionally compile in this support.
This allows simple command-line based testing of fallocate
based
On Fri, Jul 13, 2007 at 06:16:01PM +0530, Amit K. Arora wrote:
> Following is the modified version of the manpage originally submitted by
> David Chinner. Please use `nroff -man fallocate.2 | less` to view.
>
> This includes changes suggested by Heikki Orsila and Barry Naujok.
On Thu, Jul 12, 2007 at 09:34:57AM -0700, Dave Hansen wrote:
> On Thu, 2007-07-12 at 18:31 +0200, Andrea Arcangeli wrote:
> > On Fri, Jul 13, 2007 at 12:44:49AM +1000, David Chinner wrote:
> > > That's crap. Just because a machine has lots of memory does not
> > &g
On Thu, Jul 12, 2007 at 09:34:57AM -0700, Dave Hansen wrote:
On Thu, 2007-07-12 at 18:31 +0200, Andrea Arcangeli wrote:
On Fri, Jul 13, 2007 at 12:44:49AM +1000, David Chinner wrote:
That's crap. Just because a machine has lots of memory does not
make it OK to waste lots of memory
On Fri, Jul 13, 2007 at 06:16:01PM +0530, Amit K. Arora wrote:
Following is the modified version of the manpage originally submitted by
David Chinner. Please use `nroff -man fallocate.2 | less` to view.
This includes changes suggested by Heikki Orsila and Barry Naujok.
Can we get itemised
On Thu, Jul 12, 2007 at 01:14:36PM +0200, Andrea Arcangeli wrote:
> On Thu, Jul 12, 2007 at 10:12:56AM +1000, David Chinner wrote:
> > I need really large filesystems that contain both small and large files to
> > work more efficiently on small boxes where we can't throw endless amo
On Thu, Jul 12, 2007 at 12:58:13PM +0530, Suparna Bhattacharya wrote:
>
> Why don't we just merge the interface for preallocation (essentially
> enough to satisfy posix_fallocate() and the simple XFS requirement for
> space reservation without changing file size), which there is clear agreement
On Wed, Jul 11, 2007 at 11:08:36PM -0700, Jeremy Fitzhardinge wrote:
> Jesper Juhl wrote:
> >One of the big problem spots was XFS, but that got some stack usage
> >fixes recently, and the 4K stack option has been around for quite a
> >while now, so people really should have gotten around to
On Wed, Jul 11, 2007 at 11:08:36PM -0700, Jeremy Fitzhardinge wrote:
Jesper Juhl wrote:
One of the big problem spots was XFS, but that got some stack usage
fixes recently, and the 4K stack option has been around for quite a
while now, so people really should have gotten around to fixing any
On Thu, Jul 12, 2007 at 12:58:13PM +0530, Suparna Bhattacharya wrote:
Why don't we just merge the interface for preallocation (essentially
enough to satisfy posix_fallocate() and the simple XFS requirement for
space reservation without changing file size), which there is clear agreement
on
On Thu, Jul 12, 2007 at 01:14:36PM +0200, Andrea Arcangeli wrote:
On Thu, Jul 12, 2007 at 10:12:56AM +1000, David Chinner wrote:
I need really large filesystems that contain both small and large files to
work more efficiently on small boxes where we can't throw endless amounts of
RAM
Teach do_mpage_readpage() about unwritten extents so we can
always map them in get_blocks rather than they are are holes on
read. Allows setup_swap_extents() to use preallocated files on XFS
filesystems for swap files without ever needing to convert them.
Signed-Off-By: Dave Chinner <[EMAIL
Implement ->page_mkwrite in XFS.
Signed-Off-By: Dave Chinner <[EMAIL PROTECTED]>
---
fs/xfs/linux-2.6/xfs_file.c | 16
1 file changed, 16 insertions(+)
Index: 2.6.x-xfs-new/fs/xfs/linux-2.6/xfs_file.c
===
---
Generic page_mkwrite functionality.
Filesystems that make use of the VM ->page_mkwrite() callout will generally use
the same core code to implement it. There are several tricky truncate-related
issues that we need to deal with here as we cannot take the i_mutex as we
normally would for these
Upcoming XFS functionality [1] we plan to merge in 2.6.23-rc1 uses
radix trees and uses the preload functions. XFS can be built as a
module and hence we need radix_tree_preload() exported.
radix_tree_preload_end() is a static inline, so it doesn't need
exporting.
[1]
On Wed, Jul 11, 2007 at 07:16:34PM +0200, Jesper Juhl wrote:
> Hi,
>
> I'm wondering if it's time to make 4K stacks the default and to start
> considering removing the 8K stack option alltogether soon?
>
> One of the big problem spots was XFS, but that got some stack usage
> fixes recently,
On Thu, Jul 12, 2007 at 10:54:57AM +1000, Nick Piggin wrote:
> Andrew Morton wrote:
> > The fault-vs-invalidate race fix. I have belatedly learned that these
> > need
> > more work, so their state is uncertain.
>
> The more work may turn out being too much for you (although it is nothing
>
On Tue, Jul 10, 2007 at 12:11:48PM +0200, Andrea Arcangeli wrote:
> On Mon, Jul 09, 2007 at 09:20:31AM +1000, David Chinner wrote:
> > I think you've misunderstood why large block sizes are important to
> > XFS. The major benefits to XFS of larger block size have almost
&g
On Tue, Jul 10, 2007 at 12:11:48PM +0200, Andrea Arcangeli wrote:
On Mon, Jul 09, 2007 at 09:20:31AM +1000, David Chinner wrote:
I think you've misunderstood why large block sizes are important to
XFS. The major benefits to XFS of larger block size have almost
nothing to do with data
On Thu, Jul 12, 2007 at 10:54:57AM +1000, Nick Piggin wrote:
Andrew Morton wrote:
The fault-vs-invalidate race fix. I have belatedly learned that these
need
more work, so their state is uncertain.
The more work may turn out being too much for you (although it is nothing
exactly tricky
On Wed, Jul 11, 2007 at 07:16:34PM +0200, Jesper Juhl wrote:
Hi,
I'm wondering if it's time to make 4K stacks the default and to start
considering removing the 8K stack option alltogether soon?
One of the big problem spots was XFS, but that got some stack usage
fixes recently, and the
Upcoming XFS functionality [1] we plan to merge in 2.6.23-rc1 uses
radix trees and uses the preload functions. XFS can be built as a
module and hence we need radix_tree_preload() exported.
radix_tree_preload_end() is a static inline, so it doesn't need
exporting.
[1]
Generic page_mkwrite functionality.
Filesystems that make use of the VM -page_mkwrite() callout will generally use
the same core code to implement it. There are several tricky truncate-related
issues that we need to deal with here as we cannot take the i_mutex as we
normally would for these
Implement -page_mkwrite in XFS.
Signed-Off-By: Dave Chinner [EMAIL PROTECTED]
---
fs/xfs/linux-2.6/xfs_file.c | 16
1 file changed, 16 insertions(+)
Index: 2.6.x-xfs-new/fs/xfs/linux-2.6/xfs_file.c
===
---
Teach do_mpage_readpage() about unwritten extents so we can
always map them in get_blocks rather than they are are holes on
read. Allows setup_swap_extents() to use preallocated files on XFS
filesystems for swap files without ever needing to convert them.
Signed-Off-By: Dave Chinner [EMAIL
On Sat, Jul 07, 2007 at 12:26:51AM +0200, Andrea Arcangeli wrote:
> The xfs developers for example want to enlarge their filesystem
> blocksize (the filesystem blocksize has a tradeoff similar to the
> PAGE_SIZE, the larger the faster the filesystem but more disk space is
> potentially wasted),
I
On Sat, Jul 07, 2007 at 12:26:51AM +0200, Andrea Arcangeli wrote:
The xfs developers for example want to enlarge their filesystem
blocksize (the filesystem blocksize has a tradeoff similar to the
PAGE_SIZE, the larger the faster the filesystem but more disk space is
potentially wasted),
I
On Fri, Jun 29, 2007 at 10:27:05AM -0400, Jeff Garzik wrote:
> David Chinner wrote:
> >Folks,
> >
> >After updating an x86_64 machine from 2.6.21 to 2.6.22-rc6 and
> >fighting off the where-the-fuck-did-my-serial-console-go blues
> >(legacy_serial.force), I fina
On Fri, Jun 29, 2007 at 10:27:05AM -0400, Jeff Garzik wrote:
David Chinner wrote:
Folks,
After updating an x86_64 machine from 2.6.21 to 2.6.22-rc6 and
fighting off the where-the-fuck-did-my-serial-console-go blues
(legacy_serial.force), I finally discovered why the damn thing
wasn't
On Tue, Jul 03, 2007 at 07:50:26PM +0200, Bartlomiej Zolnierkiewicz wrote:
>
> Hi,
>
> On Tuesday 03 July 2007, Michal Piotrowski wrote:
>
> > IDE
> >
> > Subject: 2.6.22-rcX: hda: lost interrupt
> > References : http://lkml.org/lkml/2007/6/29/121
On Tue, Jul 03, 2007 at 07:50:26PM +0200, Bartlomiej Zolnierkiewicz wrote:
Hi,
On Tuesday 03 July 2007, Michal Piotrowski wrote:
IDE
Subject: 2.6.22-rcX: hda: lost interrupt
References : http://lkml.org/lkml/2007/6/29/121
Submitter : David Chinner [EMAIL PROTECTED]
Status
On Mon, Jul 02, 2007 at 08:28:27PM -0700, Andrew Morton wrote:
> On Tue, 3 Jul 2007 11:10:19 +1000 David Chinner <[EMAIL PROTECTED]> wrote:
>
> Seems sane, although one does wonder whether it's a worthy tradeoff. We
> add additional overhead to readpage[s]() just to avoid some
Teach do_mpage_readpage() about unwritten extents so we can
always map them in get_blocks rather than they are are holes on
read. Allows setup_swap_extents() to use preallocated files on XFS
filesystems for swap files without ever needing to convert them.
Signed-Off-By: Dave Chinner <[EMAIL
On Mon, Jul 02, 2007 at 05:05:09PM +0200, Michal Marek wrote:
> On Mon, Jul 02, 2007 at 11:40:34AM +0200, Michal Marek wrote:
> > David Chinner wrote:
> > > I think we can remove xfs_bulkstat_one_compat() completely by using
> > > the same method you used with th
On Mon, Jul 02, 2007 at 05:05:09PM +0200, Michal Marek wrote:
On Mon, Jul 02, 2007 at 11:40:34AM +0200, Michal Marek wrote:
David Chinner wrote:
I think we can remove xfs_bulkstat_one_compat() completely by using
the same method you used with the xfs_inumber_fmt functions.
You mean
Teach do_mpage_readpage() about unwritten extents so we can
always map them in get_blocks rather than they are are holes on
read. Allows setup_swap_extents() to use preallocated files on XFS
filesystems for swap files without ever needing to convert them.
Signed-Off-By: Dave Chinner [EMAIL
On Mon, Jul 02, 2007 at 08:28:27PM -0700, Andrew Morton wrote:
On Tue, 3 Jul 2007 11:10:19 +1000 David Chinner [EMAIL PROTECTED] wrote:
Seems sane, although one does wonder whether it's a worthy tradeoff. We
add additional overhead to readpage[s]() just to avoid some IO during
mkswap
On Sat, Jun 30, 2007 at 11:21:11AM +0100, Christoph Hellwig wrote:
> 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?
> >
>
On Sun, Jul 01, 2007 at 01:16:51AM +0200, Jesper Juhl wrote:
> (this is back from May 16 2007, resending since it doesn't look like
> the patch ever made it in anywhere)
http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.6-xfs/fs/xfs/xfs_vnodeops.c.diff?r1=1.698;r2=1.699;f=h
Will get merged in
On Sun, Jul 01, 2007 at 01:16:51AM +0200, Jesper Juhl wrote:
(this is back from May 16 2007, resending since it doesn't look like
the patch ever made it in anywhere)
http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.6-xfs/fs/xfs/xfs_vnodeops.c.diff?r1=1.698;r2=1.699;f=h
Will get merged in
On Sat, Jun 30, 2007 at 11:21:11AM +0100, Christoph Hellwig wrote:
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?
Folks,
After updating an x86_64 machine from 2.6.21 to 2.6.22-rc6 and
fighting off the where-the-fuck-did-my-serial-console-go blues
(legacy_serial.force), I finally discovered why the damn thing
wasn't booting - the machine was sitting there in a loop outputting
"hda: lost interrupt" over and
On Fri, Jun 29, 2007 at 08:40:00AM +0100, David Greaves wrote:
> What happens if a filesystem is frozen and I hibernate?
> Will it be thawed when I resume?
If you froze it yourself, then you'll have to thaw it yourself.
Cheers,
Dave.
--
Dave Chinner
Principal Engineer
SGI Australian Software
On Fri, Jun 29, 2007 at 08:40:00AM +0100, David Greaves wrote:
What happens if a filesystem is frozen and I hibernate?
Will it be thawed when I resume?
If you froze it yourself, then you'll have to thaw it yourself.
Cheers,
Dave.
--
Dave Chinner
Principal Engineer
SGI Australian Software
Folks,
After updating an x86_64 machine from 2.6.21 to 2.6.22-rc6 and
fighting off the where-the-fuck-did-my-serial-console-go blues
(legacy_serial.force), I finally discovered why the damn thing
wasn't booting - the machine was sitting there in a loop outputting
hda: lost interrupt over and over
On Fri, Jun 29, 2007 at 12:16:44AM +0200, Rafael J. Wysocki wrote:
> There are two solutions possible, IMO. One would be to make these workqueues
> freezable, which is possible, but hacky and Oleg didn't like that very much.
> The second would be to freeze XFS from within the hibernation code
On Wed, Jun 27, 2007 at 08:49:24PM +, Pavel Machek wrote:
> Hi!
>
> > FWIW, I'm on record stating that "sync" is not sufficient to quiesce an XFS
> > filesystem for a suspend/resume to work safely and have argued that the only
>
> Hmm, so XFS writes to disk even when its threads are frozen?
On Thu, Jun 28, 2007 at 08:20:31AM -0400, Chris Mason wrote:
> On Thu, Jun 28, 2007 at 04:44:43AM +0200, Nick Piggin wrote:
> > That's true but I don't think an extent data structure means we can
> > become too far divorced from the pagecache or the native block size
> > -- what will end up
On Thu, Jun 28, 2007 at 11:49:13PM +0530, Amit K. Arora wrote:
> On Wed, Jun 27, 2007 at 09:18:04AM +1000, David Chinner wrote:
> > On Tue, Jun 26, 2007 at 11:34:13AM -0400, Andreas Dilger wrote:
> > > On Jun 26, 2007 16:02 +0530, Amit K. Arora wrote:
> > > > On M
On Thu, Jun 28, 2007 at 11:49:13PM +0530, Amit K. Arora wrote:
On Wed, Jun 27, 2007 at 09:18:04AM +1000, David Chinner wrote:
On Tue, Jun 26, 2007 at 11:34:13AM -0400, Andreas Dilger wrote:
On Jun 26, 2007 16:02 +0530, Amit K. Arora wrote:
On Mon, Jun 25, 2007 at 03:46:26PM -0600
On Thu, Jun 28, 2007 at 08:20:31AM -0400, Chris Mason wrote:
On Thu, Jun 28, 2007 at 04:44:43AM +0200, Nick Piggin wrote:
That's true but I don't think an extent data structure means we can
become too far divorced from the pagecache or the native block size
-- what will end up happening is
On Wed, Jun 27, 2007 at 08:49:24PM +, Pavel Machek wrote:
Hi!
FWIW, I'm on record stating that sync is not sufficient to quiesce an XFS
filesystem for a suspend/resume to work safely and have argued that the only
Hmm, so XFS writes to disk even when its threads are frozen?
They
On Fri, Jun 29, 2007 at 12:16:44AM +0200, Rafael J. Wysocki wrote:
There are two solutions possible, IMO. One would be to make these workqueues
freezable, which is possible, but hacky and Oleg didn't like that very much.
The second would be to freeze XFS from within the hibernation code path,
On Tue, Jun 19, 2007 at 03:25:52PM +0200, [EMAIL PROTECTED] wrote:
> * 32bit struct xfs_fsop_bulkreq has different size and layout of
> members, no matter the alignment. Move the code out of the #else
> branch (why was it there in the first place?). Define _32 variants of
> the ioctl
On Tue, Jun 19, 2007 at 03:25:51PM +0200, [EMAIL PROTECTED] wrote:
> 32bit struct xfs_fsop_handlereq has different size and offsets (due to
> pointers). TODO: case XFS_IOC_{FSSETDM,ATTRLIST,ATTRMULTI}_BY_HANDLE
> still not handled.
Looks good. Added to my qa tree...
Cheers,
Dave.
--
Dave
On Tue, Jun 19, 2007 at 03:25:50PM +0200, [EMAIL PROTECTED] wrote:
> i386 struct xfs_fsop_geom_v1 has no padding after the last member, so
> the size is different.
Looks good. Added to my qa tree...
Cheers,
Dave.
--
Dave Chinner
Principal Engineer
SGI Australian Software Group
-
To unsubscribe
On Wed, Jun 27, 2007 at 07:50:56AM -0400, Chris Mason wrote:
> On Wed, Jun 27, 2007 at 07:32:45AM +0200, Nick Piggin wrote:
> > On Tue, Jun 26, 2007 at 08:34:49AM -0400, Chris Mason wrote:
> > > On Tue, Jun 26, 2007 at 07:23:09PM +1000, David Chinner wrote:
> > > >
On Wed, Jun 27, 2007 at 07:32:45AM +0200, Nick Piggin wrote:
> I think using fsblock to drive the IO and keep the pagecache flags
> uptodate and using a btree in the filesystem to manage extents of block
> allocations wouldn't be a bad idea though. Do any filesystems actually
> do this?
Yes. XFS.
On Wed, Jun 27, 2007 at 07:32:45AM +0200, Nick Piggin wrote:
I think using fsblock to drive the IO and keep the pagecache flags
uptodate and using a btree in the filesystem to manage extents of block
allocations wouldn't be a bad idea though. Do any filesystems actually
do this?
Yes. XFS. But
On Wed, Jun 27, 2007 at 07:50:56AM -0400, Chris Mason wrote:
On Wed, Jun 27, 2007 at 07:32:45AM +0200, Nick Piggin wrote:
On Tue, Jun 26, 2007 at 08:34:49AM -0400, Chris Mason wrote:
On Tue, Jun 26, 2007 at 07:23:09PM +1000, David Chinner wrote:
On Tue, Jun 26, 2007 at 01:55:11PM +1000
On Tue, Jun 19, 2007 at 03:25:50PM +0200, [EMAIL PROTECTED] wrote:
i386 struct xfs_fsop_geom_v1 has no padding after the last member, so
the size is different.
Looks good. Added to my qa tree...
Cheers,
Dave.
--
Dave Chinner
Principal Engineer
SGI Australian Software Group
-
To unsubscribe
On Tue, Jun 19, 2007 at 03:25:51PM +0200, [EMAIL PROTECTED] wrote:
32bit struct xfs_fsop_handlereq has different size and offsets (due to
pointers). TODO: case XFS_IOC_{FSSETDM,ATTRLIST,ATTRMULTI}_BY_HANDLE
still not handled.
Looks good. Added to my qa tree...
Cheers,
Dave.
--
Dave Chinner
On Tue, Jun 19, 2007 at 03:25:52PM +0200, [EMAIL PROTECTED] wrote:
* 32bit struct xfs_fsop_bulkreq has different size and layout of
members, no matter the alignment. Move the code out of the #else
branch (why was it there in the first place?). Define _32 variants of
the ioctl constants.
g out data blocks or preallocating new ones.
> Hmm.. I personally will call it a bug in XFS code then. :)
No, I'd call it useful. :)
> > > I think, modifying ctime/mtime should be dependent on the other flags.
> > > E.g., if we do not zero out data blocks on allocation/deallo
On Tue, Jun 26, 2007 at 11:42:50AM -0400, Andreas Dilger wrote:
> On Jun 26, 2007 16:15 +0530, Amit K. Arora wrote:
> > On Mon, Jun 25, 2007 at 03:52:39PM -0600, Andreas Dilger wrote:
> > > In XFS one of the (many) ALLOC modes is to zero existing data on allocate.
> > > For ext4 all this would
On Mon, Jun 25, 2007 at 03:52:39PM -0600, Andreas Dilger wrote:
> On Jun 25, 2007 19:15 +0530, Amit K. Arora wrote:
> > +#define FA_FL_DEALLOC 0x01 /* default is allocate */
> > +#define FA_FL_KEEP_SIZE0x02 /* default is extend/shrink size */
> > +#define FA_FL_DEL_DATA 0x04 /*
On Tue, Jun 26, 2007 at 11:34:13AM -0400, Andreas Dilger wrote:
> On Jun 26, 2007 16:02 +0530, Amit K. Arora wrote:
> > On Mon, Jun 25, 2007 at 03:46:26PM -0600, Andreas Dilger wrote:
> > > Can you clarify - what is the current behaviour when ENOSPC (or some other
> > > error) is hit? Does it
On Mon, Jun 25, 2007 at 03:46:26PM -0600, Andreas Dilger wrote:
> On Jun 25, 2007 20:33 +0530, Amit K. Arora wrote:
> > I have not implemented FA_FL_FREE_ENOSPC and FA_ZERO_SPACE flags yet, as
> > *suggested* by Andreas in http://lkml.org/lkml/2007/6/14/323 post.
> > If it is decided that these
On Mon, Jun 25, 2007 at 06:58:10PM +0530, Amit K. Arora wrote:
> 2) The above new patches (4/7 and 7/7) are based on the dicussion
>between Andreas Dilger and David Chinner on the mode argument,
>when later posted a man page on fallocate.
Can you include the man page in this
On Tue, Jun 26, 2007 at 11:35:20AM +0200, Jarek Poplawski wrote:
> On 26-06-2007 04:16, David Chinner wrote:
> > It does both - parent-first/child-second and ascending inode # order,
> > which is where the problem is. standing alone, these seem fine, but
> > they don'
On Tue, Jun 26, 2007 at 01:55:11PM +1000, Nick Piggin wrote:
> David Chinner wrote:
> >On Sun, Jun 24, 2007 at 03:45:28AM +0200, Nick Piggin wrote:
> >>I'm announcing "fsblock" now because it is quite intrusive and so I'd
> >>like to get some thoughts about
On Tue, Jun 26, 2007 at 01:55:11PM +1000, Nick Piggin wrote:
David Chinner wrote:
On Sun, Jun 24, 2007 at 03:45:28AM +0200, Nick Piggin wrote:
I'm announcing fsblock now because it is quite intrusive and so I'd
like to get some thoughts about significantly changing this core part
On Tue, Jun 26, 2007 at 11:35:20AM +0200, Jarek Poplawski wrote:
On 26-06-2007 04:16, David Chinner wrote:
It does both - parent-first/child-second and ascending inode # order,
which is where the problem is. standing alone, these seem fine, but
they don't appear to work when the child has
On Mon, Jun 25, 2007 at 03:46:26PM -0600, Andreas Dilger wrote:
On Jun 25, 2007 20:33 +0530, Amit K. Arora wrote:
I have not implemented FA_FL_FREE_ENOSPC and FA_ZERO_SPACE flags yet, as
*suggested* by Andreas in http://lkml.org/lkml/2007/6/14/323 post.
If it is decided that these flags
On Mon, Jun 25, 2007 at 06:58:10PM +0530, Amit K. Arora wrote:
2) The above new patches (4/7 and 7/7) are based on the dicussion
between Andreas Dilger and David Chinner on the mode argument,
when later posted a man page on fallocate.
Can you include the man page in this patch set
On Tue, Jun 26, 2007 at 11:34:13AM -0400, Andreas Dilger wrote:
On Jun 26, 2007 16:02 +0530, Amit K. Arora wrote:
On Mon, Jun 25, 2007 at 03:46:26PM -0600, Andreas Dilger wrote:
Can you clarify - what is the current behaviour when ENOSPC (or some other
error) is hit? Does it keep the
301 - 400 of 837 matches
Mail list logo
