linux-kernel.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: John Richard Moser <nigelenki@comcast.net>
To: James Courtier-Dutton <James@superbug.co.uk>
Cc: linux-kernel@vger.kernel.org
Subject: Re: soft update vs journaling?
Date: Sun, 22 Jan 2006 19:06:20 -0500	[thread overview]
Message-ID: <43D41DFC.5020608@comcast.net> (raw)
In-Reply-To: <43D3DC75.30703@superbug.co.uk>

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1



James Courtier-Dutton wrote:
> John Richard Moser wrote:
> 
>>
>> Unfortunately, journaling uses a chunk of space.  Imagine a journal on a
>> USB flash stick of 128M; a typical ReiserFS journal is 32 megabytes!
>> Sure it could be done in 8 or 4 or so; or (in one of my file system
>> designs) a static 16KiB block could reference dynamicly allocated
>> journal space, allowing the system to sacrifice performance and shrink
>> the journal when more space is needed.  Either way, slow media like
>> floppies will suffer, HARD; and flash devices will see a lot of
>> write/erase all over the journal area, causing wear on that spot.
>>
> 
> My understanding is that if one designed a power supply with enough
> headroom, one could remove the power and still have time to write dirty
> sectors to the USB flash stick. Would this not remove the need for a
> journaling fs on a flash stick.

Depends on how much meta-data you have to write out.  What if you just
altered 6000 files?  Now you have a ton of dentries to destroy and
inodes to invalidate, some FAT entries to free up, etc.  What if the
user just pulled the drive out of the USB port?  Or the USB port is
faulty and lost connection (I've seen it!).

> This would remove the "wear on that
> spot" problem.

Wha?  You mean remove the trigger, not the underlying problem.

> Actually USB flash sticks are a bit clever, in that they
> add an extra layer of translation to the write. I.e. If you write to the
> same sector again and again, the USB flash stick will actually write it
> to a different area of the memory each time. This is specifically done
> to save the "wear on that spot" problem.

Yeah, built-in write balancing is nice.

> 
> This "flush on power fail" approach is not so easy with a HD because it
> uses more power and takes longer to flush.

The "flush on power fail" is retarded because it takes extra hardware
and doesn't work if the USB port itself loses connection or if the user
is just dumb enough to pull/knock the drive out.  It won't work with
mini hard disks either, as you say.

"Flush on power fail" is pretty much getting a 10 minute UPS and issuing
'shutdown -h now' when the UPS signals init, which there's already
contingencies for (can also suspend to disk).  It won't help if the PSU
burns out, if the system crashes, if the power cord is pulled, or if the
dog walks around your chair and you turn and bump your foot into the
"power" button on the UPS itself.

> 
> James
> 
> 

- --
All content of all messages exchanged herein are left in the
Public Domain, unless otherwise explicitly stated.

    Creative brains are a valuable, limited resource. They shouldn't be
    wasted on re-inventing the wheel when there are so many fascinating
    new problems waiting out there.
                                                 -- Eric Steven Raymond
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.2 (GNU/Linux)
Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org

iD8DBQFD1B37hDd4aOud5P8RAsCtAJ0TZM4I9T9gE6PMbfUhMux8zrxE9wCff67G
kdlY0fvfJQXmDljz6KekSxc=
=BV+l
-----END PGP SIGNATURE-----

  reply	other threads:[~2006-01-23  0:07 UTC|newest]

Thread overview: 32+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2006-01-22  6:42 soft update vs journaling? John Richard Moser
2006-01-22  8:51 ` Jan Engelhardt
2006-01-22 18:40   ` John Richard Moser
2006-01-22 19:05   ` Adrian Bunk
2006-01-22 19:08     ` Arjan van de Ven
2006-01-22 19:25       ` Adrian Bunk
2006-01-24  2:33       ` Jörn Engel
2006-01-22  9:31 ` Theodore Ts'o
2006-01-22 18:54   ` John Richard Moser
2006-01-22 21:02     ` Theodore Ts'o
2006-01-22 22:44       ` Kyle Moffett
2006-01-23  7:24         ` Theodore Ts'o
2006-01-23 13:31           ` Mitchell Blank Jr
2006-01-23 13:33           ` Kyle Moffett
2006-01-23 13:52             ` Antonio Vargas
2006-01-23 16:48               ` Linux VFS architecture questions Kyle Moffett
2006-01-23 17:00                 ` Pekka Enberg
2006-01-23 17:50                   ` Kyle Moffett
2006-01-23 17:54                     ` Randy.Dunlap
2006-01-23 20:48           ` soft update vs journaling? Folkert van Heusden
2006-01-23  1:02       ` John Richard Moser
2006-01-22 19:50   ` Diego Calleja
2006-01-22 20:39     ` Suleiman Souhlal
2006-01-22 20:50       ` Diego Calleja
2006-01-23  1:00     ` John Richard Moser
2006-01-23  1:09       ` Suleiman Souhlal
2006-01-23  2:09         ` John Richard Moser
2006-01-22 19:26 ` James Courtier-Dutton
2006-01-23  0:06   ` John Richard Moser [this message]
2006-01-23  5:32 ` Michael Loftis
2006-01-23 18:52   ` John Richard Moser
2006-01-23 19:32     ` Matthias Andree

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=43D41DFC.5020608@comcast.net \
    --to=nigelenki@comcast.net \
    --cc=James@superbug.co.uk \
    --cc=linux-kernel@vger.kernel.org \
    /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;
as well as URLs for NNTP newsgroup(s).