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
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
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,
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,
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
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
hold that over
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
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 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_pages2_range(), what happens if we
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
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
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 &
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 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 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(mask) ) !=
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
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 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 in
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
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
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
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
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
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 since I
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 plain
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
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
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 mounted
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
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 10
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
>
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
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->
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_outstanding_credits++;
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-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 to
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 --- there
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
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)
> +
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
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
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
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
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 more to
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:
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 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 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_credits++;
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 following
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.
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
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 new
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 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 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.
>
>
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.
It
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 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 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 I
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 do
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.
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_DIRECT
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 downside it its greater CPU cost and the fact
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
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()
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() function
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 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 no cross-calls
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 combination
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 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 I've
tried at first
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
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
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 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
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 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 ;)
[..]
VFS: Can't find an ext3 filesystem on dev
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
>
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
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
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
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 do
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
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
Hi,
On Wed, May 23, 2001 at 01:01:56PM -0700, Linus Torvalds wrote:
> On Wed, 23 May 2001, Stephen C. Tweedie wrote:
> > > that the filesystems already do. And you can do it a lot _better_ than the
> > > current buffer-cache-based approach. Done right, you can actually do
Hi,
On Wed, May 23, 2001 at 01:54:15PM -0400, Alexander Viro wrote:
> On Wed, 23 May 2001 [EMAIL PROTECTED] wrote:
>
> > > But I don't want an initrd.
> > Don't be afraid of words. You wouldnt notice - it would do its
> > job and disappear just like piggyback today.
>
> Andries, initrd code is
On Wed, May 23, 2001 at 07:55:48PM +1000, Andrew Morton wrote:
> When you truncated your file, the blocks remained preallocated
> on behalf of the file, and were hence considered "used". For
> some reason, a subsequent attempt to allocate blocks for the
> same file failed to use that file's
On Wed, May 23, 2001 at 07:55:48PM +1000, Andrew Morton wrote:
When you truncated your file, the blocks remained preallocated
on behalf of the file, and were hence considered used. For
some reason, a subsequent attempt to allocate blocks for the
same file failed to use that file's
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
101 - 200 of 609 matches
Mail list logo
