Two x86-64 boxes here lock up here on 2.6.25-rc2, shortly after boot.
One running Fedora 8 + X (GNOME) and one a headless file server.
configs and lspci attached. Unable to capture any splatter so far.
Bisecting...
00:00.0 Host bridge: Intel Corporation 82955X Memory Controller Hub
00:01.0 P
Alex Tomas wrote:
So without the ability to attach specific I/O completions to bios
or support for unwritten extents directly in __mpage_writepage,
there is no way XFS can use this "generic" delayed allocation code.
I didn't say "generic", see Subject: :)
Well, it shouldn't even be in the VFS
Alex Tomas wrote:
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.
nope, this one is simple (something I'd prefer for ext4).
The XFS one is proven and the work was already
Alex Tomas wrote:
Good day,
please review ...
thanks, Alex
basic delayed allocation in VFS:
* block_prepare_write() can be passed special ->get_block() which
doesn't allocate blocks, but reserve them and mark bh delayed
* a filesystem can use mpage_da_writepages() with other ->get_block
Theodore Tso wrote:
I don't think we have a problem here. What we have now is fine, and
It's fine for ext4, but not the wider world. This is a common problem
created by parallel development when code dependencies exist.
In any case, the plan is to push all of the core bits into Linus tre
Andrew Morton wrote:
b) We do what we normally don't do and reserve the syscall slots in mainline.
If everyone agrees it's going to happen... why not?
Jeff
-
To unsubscribe from this list: send the line "unsubscribe linux-ext4" in
the body of a message to [EMAIL PROTECTED]
More major
Andreas Dilger wrote:
My comment was just that the extent doesn't have to be explicitly zero
filled on the disk, by virtue of the fact that the uninitialized flag
will cause reads to return zero.
Agreed, thanks for the clarification.
Jeff
-
To unsubscribe from this list: send the li
Andreas Dilger wrote:
On May 07, 2007 13:58 -0700, Andrew Morton wrote:
Final point: it's fairly disappointing that the present implementation is
ext4-only, and extent-only. I do think we should be aiming at an ext4
bitmap-based implementation and an ext3 implementation.
Actually, this is a
Theodore Ts'o wrote:
I've respun the ext4 development patchset, with Amit's updated fallocate
patches. I've added Dave's patch to add ia64 support to the fallocate
system call, but *not* the XFS fallocate support patches. (Probably
better for them to live in an xfs tree, where they can more eas
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, as Andrew suggested, will look like:
asmlinkag
Theodore Tso wrote:
The fastest and probably most important thing to add is some readahead
smarts to directories --- both to the htree and non-htree cases. If
you're using some kind of b-tree structure, such as XFS does for
directories, preallocation doesn't help you much. Delayed allocation
ca
[EMAIL PROTECTED] wrote:
Hi,
I am considering the online defrag function for ext4 and thinking
that your following patch set for multi-block allocation is useful
to search contiguous free blocks for the defragmentation.
"[RFC] extents,mballoc,delalloc for 2.6.16.8"
http://marc.theaimsgroup.com
On Wed, Oct 25, 2006 at 08:36:56PM +0200, Jan Kara wrote:
> Yes, but there's a question of the interface to this operation. How to
> specify which indirect block I mean? Obviously we could introduce
> separate call for remapping indirect blocks but I find this solution
> kind of clumsy...
Agreed
On Wed, Oct 25, 2006 at 08:25:30PM +0200, Jan Kara wrote:
> I see. So you mean that in our ext3meta filesystem we'd have a file
> named "add_this_extent_to_inode" and a file "reloc_inode_interval" and
> they'd be fed essentially the same info as the current ioctl interface and
> do the same thing
On Wed, Oct 25, 2006 at 07:58:51PM +0200, Jan Kara wrote:
> I've briefly looked at this and this kind of interface has some
> appeal. On the other hand it's not obvious to me, how to implement in
> this interface *atomic* operation "copy data from file F to given set of
> blocks and rewrite point
On Wed, Oct 25, 2006 at 04:54:50PM +0200, Jan Kara wrote:
> Yes, this sounds feasible. We could split the defrag ioctl into two
> pieces (addition of given extent to a file and swapping of extents), which
> can have generic interface...
An ioctl is UGLY.
This was discussed years ago. Google f
On Wed, Oct 25, 2006 at 06:11:37PM +1000, David Chinner wrote:
> On Wed, Oct 25, 2006 at 02:01:42AM -0400, Jeff Garzik wrote:
> > On Wed, Oct 25, 2006 at 03:38:23PM +1000, David Chinner wrote:
> > > On Wed, Oct 25, 2006 at 12:48:44AM -0400, Jeff Garzik wrote:
> > > So
On Wed, Oct 25, 2006 at 03:38:23PM +1000, David Chinner wrote:
> On Wed, Oct 25, 2006 at 12:48:44AM -0400, Jeff Garzik wrote:
> > On Wed, Oct 25, 2006 at 02:27:53PM +1000, David Chinner wrote:
> > > But it a race that is _easily_ handled, and applications only need to
> > &
On Wed, Oct 25, 2006 at 02:27:53PM +1000, David Chinner wrote:
> But it a race that is _easily_ handled, and applications only need to
> implement one interface, not a different method for every
> filesystem that requires deeep filesystem knowledge.
>
> Besides, you still have to handle the case w
On Wed, Oct 25, 2006 at 12:30:02PM +1000, Barry Naujok wrote:
> Could we have a more abstract method for asking the filesystem where the
> free blocks are and then using the same block addressing to tell the
> fs where to allocate/move the file's data to?
That's fundamentally racy, so you might a
On Mon, Oct 23, 2006 at 06:31:40PM +0400, Alex Tomas wrote:
> isn't that a kernel responsbility to find/allocate target blocks?
> wouldn't it better to specify desirable target group and minimal
> acceptable chunk of free blocks?
The kernel doesn't have enough knowledge to know whether or not the
21 matches
Mail list logo
