Fix the time ordering bug re-introduced by
writeback-fix-periodic-superblock-dirty-inode-flushing.patch.
The old logic moves not-yet-expired dirty inodes from s_dirty to s_io,
*only to* move them back. The move-inodes-back-and-forth thing is a mess,
which is eliminated by this patch.
Note that
From: Andrew Morton [EMAIL PROTECTED]
The per-superblock dirty-inode list super_block.s_dirty is supposed to be
sorted in reverse order of each inode's time-of-first-dirtying. This is so
that the kupdate function can avoid having to walk all the dirty inodes on the
list: it terminates the
Lars Ellenberg wrote:
meanwhile, please, anyone interessted,
the drbd paper for LinuxConf Eu 2007 is finalized.
http://www.drbd.org/fileadmin/drbd/publications/
drbd8.linux-conf.eu.2007.pdf
it does not give too much implementation detail (would be inapropriate
for conference proceedings,
On Sun, Aug 12, 2007 at 01:35:17PM +0300, Al Boldi ([EMAIL PROTECTED]) wrote:
Lars Ellenberg wrote:
meanwhile, please, anyone interessted,
the drbd paper for LinuxConf Eu 2007 is finalized.
http://www.drbd.org/fileadmin/drbd/publications/
drbd8.linux-conf.eu.2007.pdf
it does not give
On Sun, Aug 12, 2007 at 07:03:44PM +0200, Jan Engelhardt wrote:
On Aug 12 2007 09:39, [EMAIL PROTECTED] wrote:
now, I am not an expert on either option, but three are a couple things
that I
would question about the DRDB+MD option
1. when the remote machine is down, how does MD deal
On Aug 12 2007 19:42, Alan Cox wrote:
write(stdout, request);
/* reference point [A] */
read(stdin, response);
So my idea had been to launch another thread that monitors stdin for
'breakage' and unmount the fs before a user can start an operation on
myfs. So I've been
Hi Evgeniy,
Sorry for not getting back to you right away, I was on the road with
limited email access. Incidentally, the reason my mails to you keep
bouncing is, your MTA is picky about my mailer's IP reversing to a real
hostname. I will take care of that pretty soon, but for now my direct
On Tuesday 07 August 2007 13:55, Jens Axboe wrote:
I don't like structure bloat, but I do like nice design. Overloading
is a necessary evil sometimes, though. Even today, there isn't enough
room to hold bi_rw and bi_flags in the same variable on 32-bit archs,
so that concern can be scratched.
Iustin Pop wrote:
On Sun, Aug 12, 2007 at 07:03:44PM +0200, Jan Engelhardt wrote:
On Aug 12 2007 09:39, [EMAIL PROTECTED] wrote:
now, I am not an expert on either option, but three are a couple things that I
would question about the DRDB+MD option
1. when the remote machine is down, how does
per the message below MD (or DM) would need to be modified to work
reasonably well with one of the disk components being over an unreliable
link (like a network link)
are the MD/DM maintainers interested in extending their code in this
direction? or would they prefer to keep it simpler by
On Wednesday 08 August 2007 02:54, Evgeniy Polyakov wrote:
On Tue, Aug 07, 2007 at 10:55:38PM +0200, Jens Axboe
([EMAIL PROTECTED]) wrote:
So, what did we decide? To bloat bio a bit (add a queue pointer) or
to use physical device limits? The latter requires to replace all
occurence of
(previous incomplete message sent accidentally)
On Wednesday 08 August 2007 02:54, Evgeniy Polyakov wrote:
On Tue, Aug 07, 2007 at 10:55:38PM +0200, Jens Axboe wrote:
So, what did we decide? To bloat bio a bit (add a queue pointer) or
to use physical device limits? The latter requires to
On Sun, 2007-08-12 at 13:24 +0200, Jan Engelhardt wrote:
On Aug 12 2007 06:32, Al Boldi wrote:
Al Boldi wrote:
Jakob Oestergaard wrote:
Why on earth would you cripple the kernel defaults for ext3 (which is a
fine FS for boot/root filesystems), when the *fundamental* problem you
really
13 matches
Mail list logo
