Hi,
On Mon, 2007-09-17 at 11:06 -0500, Eric Sandeen wrote:
> The do_split() function for htree dir blocks is intended to split a
> leaf block to make room for a new entry. It sorts the entries in the
> original block by hash value, then moves the last half of the entries to
> the new block - wit
Hi,
On Mon, 2007-08-13 at 03:01 -0600, Andreas Dilger wrote:
> To be honest, Stephen and Andrew haven't been directly involved in
> the ext4 development. It probably makes more sense to have e.g.
> Eric Sandeen, Ted Ts'o, and MingMing Cao in their place.
Works for me.
--Stephen
-
To unsubscr
Hi,
On Sun, 2007-06-10 at 18:27 +, Pavel Machek wrote:
> > Once a f/s is read-only, there should be NO writing to
> > it. Right?
>
> Linux happily writes to filesystems mounted read-only. It will replay
> journal on them.
Only at mount time, not on unmount; and it does check whether the
u
Hi,
On Thu, 2007-06-07 at 12:01 -0400, Mark Lord wrote:
> >>mount /var/lib/mythtv -oremount,ro
> >>sync
> >>umount /var/lib/mythtv
> >
> > Did this succeed? If the application is still truncating that file, the
> > umount should have failed.
>
> Actually, what I expect to happen is
Hi,
On Mon, 2005-09-05 at 17:24, Riccardo Castellani wrote:
> I'm using FC3 with Kernel 2.6.12-1.1376.
> After few hours file system on /dev/hda8 EXT3 partition has a problem so it
> remounted in only read mode.
> Sep 5 17:34:40 mrtg kernel: EXT3-fs error (device hda8): ext3_free_blocks:
> Fre
Hi,
On Sun, 2005-09-04 at 21:33, Pavel Machek wrote:
> > - read-only mount
> > - "specatator" mount (like ro but no journal allocated for the mount,
> > no fencing needed for failed node that was mounted as specatator)
>
> I'd call it "real-read-only", and yes, that's very usefull
> mount. Cou
Hi,
On Wed, 2005-08-31 at 12:35, Glauber de Oliveira Costa wrote:
> At a first look, i thought about locking gdt-related data. But in a
> closer one, it seemed to me that we're in fact modifying a little bit
> more than that in the resize code. But all these modifications seem to
> be somehow rel
Hi,
On Thu, 2005-08-25 at 21:43, Glauber de Oliveira Costa wrote:
> Just a question here. With s_lock held by the remount code, we're
> altering the struct super_block, and believing we're safe. We try to
> acquire it inside the resize functions, because we're trying to modify
> this same data.
Hi,
On Fri, 2005-08-26 at 12:20, Steven Rostedt wrote:
> > could you try a), how clean does it get? Personally i'm much more in
> > favor of cleanliness. On the vanilla kernel a spinlock is zero bytes on
> > UP [the most RAM-sensitive platform], and it's a word on typical SMP.
It's a word, may
Hi,
On Fri, 2005-08-26 at 05:24, Steven Rostedt wrote:
> Well, I just spent several hours trying to use the b_update_lock in
> implementing something to replace the bit spinlocks for RT. It's
> getting really ugly and I just hit a stone wall.
>
> The problem is that I have two locks to work wit
Hi,
On Wed, 2005-08-24 at 22:03, Glauber de Oliveira Costa wrote:
> This simple patch provides a fix for a locking issue found in the online
> resizing code. The problem actually happened while trying to resize the
> filesystem trough the resize=xxx option in a remount.
NAK, this is wrong:
> +
Hi,
On Mon, 2005-08-15 at 19:08, Nishanth Aravamudan wrote:
> Description: Use schedule_timeout_{,un}interruptible() instead of
> set_current_state()/schedule_timeout() to reduce kernel size.
> +++ 2.6.13-rc5-mm1-dev/fs/jbd/transaction.c 2005-08-10 15:03:33.0
> -0700
> @@ -1340,8 +134
Hi,
The inotify patch just added a line
+ fsnotify_open(f->f_dentry);
to sys_open, but it missed the x86_64 compatibility sys32_open()
equivalent in arch/x86_64/ia32/sys_ia32.c.
Andi, perhaps it's time to factor out the guts of sys_open from the flag
munging to kee
Hi,
On Mon, 2005-07-11 at 22:19, Mark Fasheh wrote:
> Can we please merge this patch? I sent it to ext2-devel for comments
> last week and haven't hear anything back. It seems trivially correct and is
> testing fine - famous last words, I know :)
ACK --- looks fine to me.
--Stephen
-
To
Hi,
On Mon, 2005-07-11 at 17:10, Jan Kara wrote:
> attached patch should fix the following race:
...
> and we have sent wrong data to disk... We now clean the dirty buffer
> flag under buffer lock in all cases and hence we know that whenever a buffer
> is starting to be journaled we either fi
Hi,
On Mon, 2005-07-11 at 16:34, Jan Kara wrote:
> attached patch should close the possible race between
> journal_commit_transaction() and journal_unmap_buffer() (which adds
> buffers to committing transaction's t_forget list) that could leave
> some buffers on transaction's t_forget list (hen
Hi,
On Fri, 2005-04-15 at 21:32, Mingming Cao wrote:
> Sorry for the delaying. I was not in office these days.
No problem.
> > > Also I am concerned about the possible
> > > starvation on writers.
> > In what way?
> I was worried about the rw lock case.:)
OK, so we're both on the same track he
Hi,
On Wed, 2005-04-06 at 11:01, Hifumi Hisashi wrote:
> I have measured the bh refcount before the buffer_uptodate() for a few days.
> I found out that the bh refcount sometimes reached to 0 .
> So, I think following modifications are effective.
>
> diff -Nru 2.4.30-rc3/fs/jbd/commit.c 2.4.30-r
Hi,
On Wed, 2005-04-13 at 00:27, Mingming Cao wrote:
> > I wonder if there's not a simple solution for this --- mark the window
> > as "provisional", and if any other task tries to allocate in the space
> > immediately following such a window, it needs to block until that window
> > is released.
Hi,
On Mon, 2005-04-11 at 12:36, Jan Kara wrote:
> > The prevention of multiple writes in this case should also improve
> > performance a little.
> >
> > That ought to be pretty straightforward, I think. The existing cases
> > where we remove buffers from a checkpoint shouldn't have to care abo
Hi,
On Wed, 2005-04-06 at 02:23, Andrew Morton wrote:
> Nobody has noticed the now-fixed leak since 2.6.6 and this one appears to
> be 100x slower. Which is fortunate because this one is going to take a
> long time to fix. I'll poke at it some more.
OK, I'm now at the stage where I can kick of
Hi,
On Tue, 2005-04-12 at 07:41, Mingming Cao wrote:
> > Note that this may improve average case latencies, but it's not likely
> > to improve worst-case ones. We still need a write lock to install a new
> > window, and that's going to have to wait for us to finish finding a free
> > bit even if
Hi,
On Mon, 2005-04-11 at 21:46, Andrew Morton wrote:
> "Stephen C. Tweedie" <[EMAIL PROTECTED]> wrote:
> >
> > Andrew, what was the exact illegal state of the pages you were seeing
> > when fixing that recent leak? It looks like it's nothing more compl
Hi,
On Mon, 2005-04-11 at 19:38, Mingming Cao wrote:
> I agree. We should not skip the home block group of the file. I guess
> what I was suggesting is, if allocation from the home group failed and
> we continuing the linear search the rest of block groups, we could
> probably try to skip the bl
Hi,
On Thu, 2005-04-07 at 16:51, Stephen C. Tweedie wrote:
> I'm currently running with the buffer-trace debug patch, on 2.4, with a
> custom patch to put every buffer jbd ever sees onto a per-superblock
> list, and remove it only when the bh is destroyed in
> put_unused_b
Hi,
On Fri, 2005-04-08 at 19:10, Mingming Cao wrote:
> > It still needs to be done under locking to prevent us from expanding
> > over the next window, though. And having to take and drop a spinlock a
> > dozen times or more just to find out that there are no usable free
> > blocks in the curren
Hi,
On Fri, 2005-04-08 at 18:14, Badari Pulavarty wrote:
> I get OOPs in log_do_checkpoint() while using ext3 quotas.
> Is this anyway related to what you are working on ?
>
> Unable to handle kernel NULL pointer dereference at virtual address
>
Doesn't look like it, no. If we underst
Hi,
On Fri, 2005-04-08 at 00:37, Mingming Cao wrote:
> Actually, we do not have to do an rbtree link and unlink for every
> window we search. If the reserved window(old) has no free bit and the
> new reservable window's is right after the old one, no need to unlink
> the old window from the rbtr
Hi,
On Mon, 2005-04-04 at 10:04, Jan Kara wrote:
> In log_do_checkpoint() we go through the t_checkpoint_list of a
> transaction and call __flush_buffer() on each buffer. Suppose there is
> just one buffer on the list and it is dirty. __flush_buffer() sees it and
> puts it to an array of buffer
Hi,
On Wed, 2005-04-06 at 21:10, Stephen C. Tweedie wrote:
> However, 2.6 is suspected of still having leaks in ext3. To be certain
> that we're not just backporting one of those to 2.4, we need to
> understand who exactly is going to clean up these bh's if they are in
&g
Hi,
On Thu, 2005-04-07 at 09:14, Ingo Molnar wrote:
> doesnt the first option also allow searches to be in parallel?
In terms of CPU usage, yes. But either we use large windows, in which
case we *can't* search remotely near areas of the disk in parallel; or
we use small windows, in which case f
Hi,
On Wed, 2005-04-06 at 11:01, Hifumi Hisashi wrote:
> I have measured the bh refcount before the buffer_uptodate() for a few days.
> I found out that the bh refcount sometimes reached to 0 .
> So, I think following modifications are effective.
Thanks --- it certainly looks like this should fi
Hi,
On Wed, 2005-04-06 at 17:53, Mingming Cao wrote:
> > Possible, but not necessarily nice. If you've got a nearly-full disk,
> > most bits will be already allocated. As you scan the bitmaps, it may
> > take quite a while to find a free bit; do you really want to (a) lock
> > the whole block g
Hi,
On Wed, 2005-04-06 at 11:01, Hifumi Hisashi wrote:
> >Certainly it's normal for a short read/write to imply either error or
> >EOF, without the error necessarily needing to be returned explicitly.
> >I'm not convinced that the Singleunix language actually requires that,
> >but it seems th
Hi,
On Wed, 2005-04-06 at 06:35, Mingming Cao wrote:
> It seems we are holding the rsv_block while searching the bitmap for a
> free bit.
Probably something to avoid!
> In alloc_new_reservation(), we first find a available to
> create a reservation window, then we check the bitmap to see if i
Hi,
On Wed, 2005-03-30 at 12:59, Marcelo Tosatti wrote:
> > I'm not certain that this is right, but it seems possible and would
> > explain the symptoms. Maybe Stephen or Andrew could comments?
>
> Andrew, Stephen?
Sorry, was offline for a week last week; I'll try to look at this more
closely
Hi,
On Mon, 2005-04-04 at 02:35, Andrew Morton wrote:
> Without the below patch it's possible to make ext3 leak at around a
> megabyte per minute by arranging for the fs to run a commit every 50
> milliseconds, btw.
Ouch!
> (Stephen, please review...)
Doing so now.
> The patch teaches journa
Hi,
On Thu, 2005-03-24 at 19:38, Chris Wright wrote:
> OK, good to know. When I last checked you were working on a higher risk
> yet more complete fix, and I thought we'd wait for that one to stabilize.
> Looks like the one Jan attached is the better -stable candidate?
Definitely; it's the one
Hi,
On Thu, 2005-03-24 at 10:39, Jan Kara wrote:
> Actually the patch you atached showed in the end as not covering all
> the cases and so Stephen agreed to stay with the first try (attached)
> which should cover all known cases (although it's not so nice).
Right. The later patch is getting r
Hi,
On Tue, 2005-03-22 at 03:51, Andrew Morton wrote:
> The spec says "Write I/O operations on the file descriptor shall complete
> as defined by synchronized I/O file integrity completion".
>
> Is ftruncate a "write I/O operation"? No.
SUS seems to be pretty clear on this. The syscall descri
Hi,
On Thu, 2005-03-17 at 17:23, Stephen C. Tweedie wrote:
> I wrote a small program to calculate the total indirect tree overhead
> for any given file size, and 0x1ff7fffe000 turned out to be the largest
> file we can get without the total i_blocks overflowing 2^32.
>
> But i
Hi all,
As discussed before, we can overflow i_blocks in ext2/ext3 inodes by
growing a file up to 2TB. That gives us 2^32 sectors of data in the
file; but once you add on the indirect tree and possible EA/ACL
metadata, i_blocks will wrap beyond 2^32. Consensus seemed to be that
the best way to a
Hi,
On Tue, 2005-03-15 at 04:54, jmerkey wrote:
> Good Question. Where are the standard tools in FC2 and FC3 for these types?
For LVM, the lvm2 package contains all the necessary tools. I know
Alasdair did some kernel fixes for lvm2 striping on >2TB partitions
recently, though, so older kernel
Hi,
On Wed, 2005-03-09 at 13:28, Jan Kara wrote:
> Hmm. I see for example a place at jbd/commit.c, line 287 (which you
> did not change in your patch) which does this and doesn't seem to be
> protected against journal_unmap_buffer() (but maybe I miss something).
> Not that I'd find that race pr
Hi,
On Tue, 2005-03-08 at 15:12, Jan Kara wrote:
> Isn't also the following scenario dangerous?
>
> __journal_unfile_buffer(jh);
> journal_remove_journal_head(bh);
It depends. I think the biggest problem here is that there's really no
written rule protecting this stuff universally. But
Hi,
On Mon, 2005-03-07 at 21:08, Stephen C. Tweedie wrote:
> Right, that was what I was thinking might be possible. But for now I've
> just done the simple patch --- make sure we don't clear
> jh->b_transaction when we're just refiling buffers from one list to
>
Hi,
On Tue, 2005-03-08 at 06:49, Chris Wright wrote:
> Yes, we are intending to pick up bits from -ac (you might have missed
> that in another thread).
There's actually a successor patch to that which I'm just about to get
feedback on here and on ext2-devel. It's higher-risk than the one Alan
h
Hi,
On Tue, 2005-03-08 at 09:28, Stephen C. Tweedie wrote:
> I think it should be OK just to move the page->mapping != mapping test
> above the page>index > end test. Sure, if all the pages have been
> stolen by the time we see them, then we'll repeat without advancing
&g
Hi,
On Mon, 2005-03-07 at 23:50, Andrew Morton wrote:
> truncate_inode_pages_range() seems to dtrt here. Can we do it in the same
> manner in invalidate_inode_pages2_range()?
>
>
> Something like:
> - if (page->mapping != mapping || page->index > end) {
> +
Hi,
On Mon, 2005-03-07 at 21:22, Stephen C. Tweedie wrote:
> altgr-scrlck is showing a range of EIPs all in ext3_direct_IO->
> invalidate_inode_pages2_range(). I'm seeing
>
> invalidate_inode_pages2_range()->pagevec_lookup()->find_get_pages()
In invalidate_inode_pa
Hi,
On Mon, 2005-03-07 at 21:11, Andrew Morton wrote:
> > I'm having trouble testing it, though --- I seem to be getting livelocks
> > in O_DIRECT running 400 fsstress processes in parallel; ring any bells?
>
> Nope. I dont think anyone has been that cruel to ext3 for a while.
> I assume this
Hi,
On Mon, 2005-03-07 at 20:31, Andrew Morton wrote:
> jbd_lock_bh_journal_head() is supposed to be a
> finegrained innermost lock whose mandate is purely for atomicity of adding
> and removing the journal_head and the b_jcount refcounting. I don't recall
> there being any deeper meaning than t
Hi,
On Mon, 2005-03-07 at 16:40, Stephen C. Tweedie wrote:
> Andrew, can you remember why we ended up with both of those locks in the
> first place? If we can do it, the efficient way out here is to abandon
> the journal_head_lock and use the bh_state_lock for both. We already
> ho
Hi,
On Sat, 2005-03-05 at 00:04, Andrew Morton wrote:
> Perhaps we could also fix this by elevating b_jcount whenever the jh is
> being moved between lists?
Possible. But jcount isn't atomic, and it requires the bh_journal_head
lock to modify. Taking and dropping the lock twice around the
__un
Hi,
On Mon, 2005-03-07 at 14:50, Jan Kara wrote:
> I believe the other places should be safe (mostly by luck) as the
> caller has made sure that __journal_remove_journal_head() won't do
> anything (e.g. set b_transaction, b_next_transaction or such).
Right; I've been looking through all the jo
Hi,
On Fri, 2005-03-04 at 23:17, Badari Pulavarty wrote:
> I looked at few journalling bugs recently on RHEL4 testing here.
> I am wondering if your patch fixes this following BUG also ?
> I never got to bottom of some of these journal panics -
> since they are not easily reproducible
Right...
Hi all,
For the past few months there has been a slow but steady trickle of
reports of oopses in kjournald. Recently I got a couple of reports that
were repeatable enough to rerun with extra debugging code.
It turns out that we're releasing a journal_head while it is still
linked onto the transa
Hi,
On Tue, 2005-02-15 at 23:29, Mitchell Blank Jr wrote:
> Of course that's less efficient though since "mask" is probably constant..
> so now the endian conversion changed from compile-time to run-time.
>
> Would something like
>
> ( ( EXT3_SB(sb)->s_es->s_feature_compat & cpu_to_le32(m
Hi,
On Tue, 2005-02-15 at 10:46, Alexey Dobriyan wrote:
> - if ((ret = EXT3_HAS_RO_COMPAT_FEATURE(sb,
> - ~EXT3_FEATURE_RO_COMPAT_SUPP))) {
> + if ((ret = le32_to_cpu(EXT3_HAS_RO_COMPAT_FEATURE(sb,
> +
Hi,
On Fri, 2005-02-11 at 21:27, Andreas Dilger wrote:
> > Trouble is, that limit *should* be an i_blocks limit, because i_blocks
> > is still 32-bits, and (more importantly) is multiplied by the fs
> > blocksize / 512 in stat(2) to return st_blocks in 512-byte chunks.
> > Overflow 2^32 sectors
Hi all,
In testing large (>4TB) device support on 2.6, I've been using a simple
write/verify test to check both block device and regular file
correctness.
Set to write 1MB poison patterns for the whole of a file until EOF is
encountered, it worked just fine on ext3: the file got a short write on
Hi,
On Sat, 2005-02-05 at 19:49, Mikael Pettersson wrote:
> That leaves either the FC2 or FC3 installer kernels: one of
> them must have created the xattrs.
An FC3 install with SELinux would certainly create xattrs. Everywhere.
--Stephen
-
To unsubscribe from this list: send the line "unsubscr
Hi,
On Sun, 2005-01-30 at 10:55, Alex Tomas wrote:
> yup, you're right. so, here is an implementation of this.
> tested on UP/SMP by dbench/fsx. Stephen, Andrew, could you
> review the patch and give it a run?
Just to say I haven't forgotten, just been battling this week against
all sorts of ap
Hi,
On Fri, 2005-02-04 at 13:10, Mikael Pettersson wrote:
> > Plain upstream 2.4.28? If so, that's probably the trouble, as 2.4
> > doesn't have any xattr support, so if you delete a file on 2.4 it won't
> > delete the xattr block for it.
>
> 2.4.28 - certainly I've used that at lot.
But pl
Hi,
On Fri, 2005-02-04 at 08:25, Mikael Pettersson wrote:
> > In which kernel(s) exactly? There was a fix for that applied fairly
> > recently upstream.
>
> I've been seeing this over the last couple of months, with
> (at least) 2.4.28 and newer, and 2.6.9 and newer standard kernels.
> But si
Hi,
On Thu, 2005-02-03 at 22:42, Mikael Pettersson wrote:
> I believe there is some accounting error in the ext3 code
> for the case when CONFIG_EXT3_FS_XATTR is not selected.
>
> Whenever any one of my development boxes triggers an fsck
> at boot because some file system, usually /, has been mou
Hi,
On Fri, 2005-01-28 at 20:15, Jeffrey E. Hundstad wrote:
> >>Does linux-2.6.11-rc2 have both the linux-2.6.10-ac10 fix and the xattr
> >>problem fixed?
> >Not sure about how much of -ac went in, but it has the xattr fix.
> I've had my machine that would crash daily if not hourly stay up for
Hi,
On Thu, 2005-01-27 at 07:57, Al Viro wrote:
> Note that fs users of file_fsync() are definitely not going to be
> involved into contention here - they need opened file => held active
> reference to superblock.
> So we are left only with fs-internal asynchronous callers of
> lock_
Hi,
On Tue, 2005-01-25 at 19:30, Alex Tomas wrote:
> >> journal_dirty_metadata(handle, bh)
> >> {
> >> transaction->t_reserved--;
> >> handle->h_buffer_credits--;
> >> if (jh->b_tcount > 0) {
> >> /* modifed, no need to track it any more */
> >> transaction-> t
Hi,
On Tue, 2005-01-25 at 14:36, Alex Tomas wrote:
> Hi, could you review the following solution?
>
>
> t_outstanding_credits - number of _modified_ blocks in the transaction
> t_reserved - number of blocks all running handle reserved
> transaction size = t_outstanding_credits + t_reserved;
Hi,
On Tue, 2005-01-25 at 15:09, Jeffrey Hundstad wrote:
> >> Bad things happening to journaled filesystem machines
> >> Oops in kjournald
> I wonder if there are several problems. Alan Cox claimed that there was
> a fix in linux-2.6.10-ac10 that might alleviate the problem.
I'm not sure --
Hi,
On Mon, 2005-01-17 at 21:31, Jeffrey Hundstad wrote:
> For more of this look up subjects:
> Bad things happening to journaled filesystem machines
> Oops in kjournald
That seems to have been due to the xattr problems recently fixed in
Linus's tree. The xattr race was allowing one process
Hi,
On Mon, 2005-01-24 at 22:24, Alex Tomas wrote:
> hmmm. that's a good catch. so, with this patch A increments h_buffer_credits
> and this one will go to the t_outstanding_credits while the buffer is still
> part of the transaction. indeed, an imbalance.
>
> probably something like the followin
Hi,
On Wed, 2005-01-19 at 15:32, Alex Tomas wrote:
> @@ -1178,8 +1199,40 @@
> void
> journal_release_buffer(handle_t *handle, struct buffer_head *bh, int credits)
> {
> + /* return credit back to the handle if it was really spent */
> + if (credits)
> + handle->h_buffer_cre
Hi,
On Mon, 2005-01-24 at 20:22, Alex Tomas wrote:
> during truncate ext3 calls journal_forget() for freed blocks, but
> before these blocks go to the transaction and jbd reserves space
> in log for them (->t_outstanding_credits). also, journal_forget()
> removes these blocks from the transaction
Hi,
On Mon, 2005-01-24 at 19:27, Alex Tomas wrote:
> oops. i overlooked this line. so, the fix becomes minor improvement patch ;)
Agreed, but a worthwhile one anyway. I'm still worried if you've seen
tests where this patch definitely cured a journal overflow, though ---
if so, it may be masking
Hi,
On Wed, 2005-01-19 at 15:32, Alex Tomas wrote:
> during truncate ext3 calls journal_forget() for freed blocks, but
> before these blocks go to the transaction and jbd reserves space
> in log for them (->t_outstanding_credits). also, journal_forget()
> removes these blocks from the transaction
Hi,
On Mon, 2005-01-24 at 17:47, Alex Tomas wrote:
> SCT> I don't see how that "limit" is relevant here. ...
> if (bufs == ARRAY_SIZE(wbuf) ||
> commit_transaction->t_buffers == NULL ||
> space_left < sizeof(journal_block_tag_t) + 16) {
Hi,
On Wed, 2005-01-19 at 15:32, Alex Tomas wrote:
> under some quite high load, jbd can hit J_ASSERT(journal->j_free > 1)
> in journal_next_log_block(). The cause is the following:
>
> journal_commit_transaction()
> {
> struct buffer_head *wbuf[64];
> /* If there's no mo
Hi Andreas,
On Thu, 2005-01-20 at 02:01, Andreas Gruenbacher wrote:
> here is a set of fixes for ext3 in-inode attributes:
Obvious first question --- have these diffs survived the same
torture-by-tridgell that the previous batch suffered?
Cheers,
Stephen
-
To unsubscribe from this list: send
Hi,
On Fri, 2005-01-21 at 21:48, Andreas Gruenbacher wrote:
> Well, we could split EXT3_STATE_NEW into a "GOOD_OLD_NEW" flag for the
> first 128 bytes and a "BIG_INODE_NEW" flag for the rest, and only
> initialize the rest in the xattr code when necessary. Not any better it
> I suppose.
Agreed.
Hi,
On Thu, 2005-01-20 at 18:22, Andreas Gruenbacher wrote:
> When a new inode is created, ext3_new_inode sets the EXT3_STATE_NEW
> flag, which tells ext3_do_update_inode to zero out the inode before
> filling in the inode's data. When a file is created in a directory with
> a default acl, the ne
Hi,
On Thu, Jul 19, 2001 at 03:54:00PM -0600, Peter J. Braam wrote:
> I'm trying to export a symbol (journal_begin/end) from
> fs/reiserfs/journal.c. To export the symbols I added to the Makefile:
> export-objs := journal.o
>
> There is also a file fs/jbd/journal.c which exports symbols.
>
> I
Hi,
On Wed, Jul 04, 2001 at 08:23:10PM +, Miquel van Smoorenburg wrote:
> >huge copies. But what part of the normal handling of sequential files
> >would O_SEQUENTIAL change? Good handling of sequential files should
> >be the default, not an explicitly-requested feature.
>
> exactly what
Hi,
On Thu, Jul 05, 2001 at 10:28:35AM +0800, michaelc wrote:
>Thank you very much for your kindly guide, and I have two question to ask
>you, One question is, Is kmap_high intended to be called merely in the user
>context, so the highmem pages are mapped into user process page
Hi,
On Wed, Jul 04, 2001 at 06:27:13PM +, Miquel van Smoorenburg wrote:
> In article <[EMAIL PROTECTED]>,
> Stephen C. Tweedie <[EMAIL PROTECTED]> wrote:
> >For these reasons, buffered IO is often faster than O_DIRECT for pure
> >sequential access. The downsi
Hi,
On Wed, Jul 04, 2001 at 12:34:35AM +0400, Samium Gromoff wrote:
>
> This is interesting, because one real advantage
> of O_DIRECT are these greased weasel fast 15-20 Mb/s
> file copies, which ones makes windoze users to look
> on us as on lesser beings.
Not true.
O_DIRE
Hi,
On Tue, Jul 03, 2001 at 10:47:20PM +1000, Paul Mackerras wrote:
> Stephen C. Tweedie writes:
>
> On PPC it is a bit different. Flushing a single TLB entry is
> relatively cheap - the hardware broadcasts the TLB invalidation on the
> bus (in most implementations) so there are
Hi,
On Tue, Jul 03, 2001 at 08:10:39AM -0700, Daryll Strauss wrote:
> I recall hearing about a problem with the md device and raw IO. It was
> something about the block sizes not matching causing performance
> problems. Has anything been done to improve those issues?
The problem is a combinatio
Hi,
On Fri, Jun 29, 2001 at 02:39:00AM -0700, Dan Kegel wrote:
> It supports raw partitions, which is good; that might satisfy my
> boss (although the administration will be a pain, and I'm not
> sure whether it's really supported by Dell RAID devices).
All block devices support raw IO --- the
Hi,
On Fri, Jun 29, 2001 at 03:06:01PM +0800, michaelc wrote:
> I found that the kmap_high function didn't call __flush_tlb_one()
> when it mapped a highmem page sucessfully, and I think it maybe
> cause the problem that TLB may store obslete page table entries, but
> the kmap_atomic() functi
Hi,
On Thu, Jun 28, 2001 at 09:07:52AM +0900, NIIBE Yutaka wrote:
> Marcelo Tosatti wrote:
> > I think Stephen C. Tweedie has some considerations about the cache
> > flushing calls on do_swap_page().
>
> Yup. IIRC, he said that flushing cache at do_swap_page() (which
Hi,
On Tue, Jun 26, 2001 at 11:09:33AM +0300, Ville Herva wrote:
> Well, I for one use the 2.2 ide patches extensively (on almost all of my
> machines, including a heavy-duty backup server)
It is highly hardware-dependent. A huge amount of effort was spent
early in 2.4 getting blacklists and h
Hi,
On Mon, Jun 25, 2001 at 08:16:12PM +0200, Florian Lohoff wrote:
>
> oops in iput - Kernel 2.2.19/i386 + ide-udma patches + ext3 patches (0.0.7a)
The ide-udma patches for 2.2 haven't had nearly the testing of the 2.4
ones, and simply can't be trusted as a baseline for debugging other
code.
Hi,
On Thu, May 31, 2001 at 09:57:51AM -0700, Hans Reiser wrote:
> > /etc/hosts (or anywhere). As a tesult, startx hung starting X server; it was
> > not possible to switch to alpha console or kill X server. I pressed reset
> > and after reboot looked into /var/log/XFree86*log - and there were a
Hi,
On Sat, May 26, 2001 at 10:54:39AM +0100, Steve Dodd wrote:
> On Wed, May 23, 2001 at 01:06:16PM +0100, Stephen C. Tweedie wrote:
> > On Wed, May 23, 2001 at 02:00:13PM +0200, Florian Lohoff wrote:
>
> > > i think this message should be removed ;)
> [..]
>
Hi,
On Fri, May 25, 2001 at 02:24:52PM -0400, Alexander Viro wrote:
> If you are OK with adding two extra arguments to ->readpage() I could
> submit a patch replacing that with plain and simple page cache by tomorrow.
> It should not be a problem to port, but I want to get some sleep before
> te
Hi,
On Fri, May 25, 2001 at 09:09:37AM -0600, Eric W. Biederman wrote:
> The case we don't get quite right are partial reads that hit cached
> data, on a page that doesn't have PG_Uptodate set. We don't actually
> need to do the I/O on the surrounding page to satisfy the read
> request. But we
Hi,
On Fri, May 25, 2001 at 10:24:49AM +1000, Andrew Morton wrote:
> For example, when we miss the goal block we search forward
> up to 63 blocks for a *single* free block, and use that.
> Perhaps we shouldn't?
The reasoning here is that it's much cheaper to go to a single block
which is very n
Hi,
On Thu, May 24, 2001 at 11:24:10AM -0600, Andreas Dilger wrote:
> How have you done the ext3 preallocation code?
Preallocation is currently disabled in ext3. Eventually I'll probably
get it going by adding a journal prepare-commit callback to allow the
filesystem to flush preallocation be
1 - 100 of 328 matches
Mail list logo
