mirror of https://lore.kernel.org/lkml/
 help / color / mirror / Atom feed
From: Pavel Machek <pavel@suse.cz>
To: Mikulas Patocka <mikulas@artax.karlin.mff.cuni.cz>
Cc: Jeff Mahoney <jeffm@suse.com>,
	Anton Altaparmakov <aia21@cam.ac.uk>,
	Glauber de Oliveira Costa <glommer@br.ibm.com>,
	linux-kernel@vger.kernel.org, linux-fsdevel@vger.kernel.org,
	ext2-devel@lists.sourceforge.net, hirofumi@mail.parknet.co.jp,
	linux-ntfs-dev@lists.sourceforge.net, aia21@cantab.net,
	hch@infradead.org, viro@zeniv.linux.org.uk, akpm@osdl.org
Subject: Re: [PATCH] Use of getblk differs between locations
Date: Thu, 13 Oct 2005 13:17:07 +0200	[thread overview]
Message-ID: <20051013111707.GB516@openzaurus.ucw.cz> (raw)
In-Reply-To: <Pine.LNX.4.62.0510122208210.11573@artax.karlin.mff.cuni.cz>

Hi!

> >>- the write of these data waits until the dialog window is 
> >>displayed,
> >>user inserts the device and clicks 'OK'
> >
> >No, it's not, and deadlock is definitely possible. However, if we're 
> >at
> >the point where memory is tight enough that it's an issue, the timer 
> >can
> >expire and all the pending i/o is dropped just as it would be without
> >the multipath code enabled.
> >
> >I'm not saying it's a solution ready for production, just a good
> >starting point.
> 
> But discarding data sometimes on USB unplug is even worse than 
> discarding data always --- users will by experimenting learn that 

*Good starting point*.

Anyway, one solution would be to simply mlockall() on that
replugitd and/or make dirty data hdd based
(not ram based) and/or
restricting dirty buffers to 10MB for removable media.

				Pavel
-- 
64 bytes from 195.113.31.123: icmp_seq=28 ttl=51 time=448769.1 ms         


  parent reply	other threads:[~2005-10-14  9:28 UTC|newest]

Thread overview: 42+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2005-10-10 20:45 Glauber de Oliveira Costa
2005-10-10 21:20 ` Anton Altaparmakov
2005-10-10 21:46   ` Glauber de Oliveira Costa
2005-10-10 21:58     ` Mikulas Patocka
2005-10-10 22:25       ` Anton Altaparmakov
2005-10-10 22:49         ` Mikulas Patocka
2005-10-10 23:12           ` Glauber de Oliveira Costa
2005-10-10 23:16             ` Mikulas Patocka
2005-10-10 23:33               ` Glauber de Oliveira Costa
2005-10-10 23:34                 ` Mikulas Patocka
2005-10-10 23:49                   ` Glauber de Oliveira Costa
2005-10-11  7:52           ` Anton Altaparmakov
2005-10-12 19:51             ` Jeff Mahoney
2005-10-12 19:59               ` Mikulas Patocka
2005-10-12 20:07                 ` Jeff Mahoney
2005-10-12 20:12                   ` Mikulas Patocka
2005-10-12 20:14                     ` Anton Altaparmakov
2005-10-12 20:31                       ` Mikulas Patocka
2005-10-12 21:19                         ` Jeff Mahoney
2005-10-12 21:35                         ` Anton Altaparmakov
2005-10-13  0:09                     ` Jamie Lokier
2005-10-13  0:21                       ` Mikulas Patocka
2005-10-13  0:27                         ` Jamie Lokier
2005-10-13 11:17                     ` Pavel Machek [this message]
2005-10-14 16:52                       ` Jamie Lokier
2005-10-14 18:26                         ` Mikulas Patocka
2005-10-13  0:05                   ` Jamie Lokier
2005-10-12 20:08               ` Anton Altaparmakov
2005-10-10 22:36       ` Glauber de Oliveira Costa
2005-10-10 22:28         ` Anton Altaparmakov
2005-10-10 23:36           ` Andrew Morton
2005-10-11  0:07             ` Glauber de Oliveira Costa
2005-10-11  0:05               ` Al Viro
2005-10-11  0:40                 ` Glauber de Oliveira Costa
2005-10-11 12:35                   ` Jan Hudec
2005-10-11  0:09             ` Mikulas Patocka
2005-10-11  1:07               ` Andrew Morton
2005-10-11  1:20                 ` Mikulas Patocka
2005-10-11  5:02                   ` Andrew Morton
2005-10-11  8:07                   ` Anton Altaparmakov
2005-10-11  8:01                 ` Anton Altaparmakov
2005-10-13  0:58                   ` Mike Christie

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20051013111707.GB516@openzaurus.ucw.cz \
    --to=pavel@suse.cz \
    --cc=aia21@cam.ac.uk \
    --cc=aia21@cantab.net \
    --cc=akpm@osdl.org \
    --cc=ext2-devel@lists.sourceforge.net \
    --cc=glommer@br.ibm.com \
    --cc=hch@infradead.org \
    --cc=hirofumi@mail.parknet.co.jp \
    --cc=jeffm@suse.com \
    --cc=linux-fsdevel@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-ntfs-dev@lists.sourceforge.net \
    --cc=mikulas@artax.karlin.mff.cuni.cz \
    --cc=viro@zeniv.linux.org.uk \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox

all inboxes | Powered by JetHome®