All of lore.kernel.org
 help / color / mirror / Atom feed
From: Denis Vlasenko <vda@ilport.com.ua>
To: Etienne Lorrain <etienne_lorrain@yahoo.fr>,
	linux-kernel@vger.kernel.org, machida@sm.sony.co.jp
Subject: Re: [RFD] FAT robustness
Date: Wed, 20 Jul 2005 10:35:41 +0300	[thread overview]
Message-ID: <200507201035.41877.vda@ilport.com.ua> (raw)
In-Reply-To: <20050719165821.96544.qmail@web26907.mail.ukl.yahoo.com>

On Tuesday 19 July 2005 19:58, Etienne Lorrain wrote:
> > I'd like to have a discussion about FAT robustness.
> > Please give your thought, comments and related issues.
> 
>   What I would like is to treat completely differently writing to
>  FAT (writing to a removeable drive) which need a complete "mount",
>  and just reading quickly a file (a standard use of removeable devices).
> 
>  Basically, to read you would not need to mount the partition, just
>  read /readfs/fd1 which uses two or three functions accessing /dev/fd1
>  in raw mode to read the filesystem descriptor and the root directory.
>  Same for /readfs/cdrom and /readfs/sda4 (USB drive).
>  The only cache would be the one provided by /dev/fd1 - a kind of
>  mount read-only at each file opening.
> 
>  This system would be disabled if the partition is already mounted
>  read/write somewhere - but as long as you do not try to write to
>  a removeable disk you can extract it at any time.
> 
>   The two or three function I am talking of are located in Gujin
>  "fs.c" file to access read-only FAT12/16/32, EXT2/3 and ISOFS
>  ( http://gujin.org ). Just few kilobytes - and some source
>  modifications for that use.

I think we will be better with more generic 'flush all dirty data
and mark superblock as clean asap' behaviour, aka 'weak O_SYNC',
so that we can remove e.g. USB removable almost anytime (can't safely
remove it _only while it is being written to_).
--
vda


  parent reply	other threads:[~2005-07-20  7:36 UTC|newest]

Thread overview: 10+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2005-07-19 16:58 [RFD] FAT robustness Etienne Lorrain
2005-07-19 21:53 ` Horst von Brand
2005-07-20  7:35 ` Denis Vlasenko [this message]
  -- strict thread matches above, loose matches on Subject: below --
2005-07-17  6:41 Hiroyuki Machida
2005-07-18 11:57 ` Paulo Marques
2005-07-20 18:03   ` Hiroyuki Machida
2005-07-21 14:56     ` OGAWA Hirofumi
2005-07-21  5:22   ` Pavel Machek
2005-07-19 14:54 ` OGAWA Hirofumi
2005-07-21 12:15   ` Hiroyuki Machida

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=200507201035.41877.vda@ilport.com.ua \
    --to=vda@ilport.com.ua \
    --cc=etienne_lorrain@yahoo.fr \
    --cc=linux-kernel@vger.kernel.org \
    --cc=machida@sm.sony.co.jp \
    /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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.