[openbeos] Re: sync daemon?
- From: "André Braga" <meianoite@xxxxxxxxx>
- To: openbeos@xxxxxxxxxxxxx
- Date: Fri, 19 Jan 2007 15:53:46 -0200
On 1/19/07, Marcus Overhagen <marcusoverhagen@xxxxxxxx> wrote:
André Braga wrote:
> b) generate a trickle of network traffic which sometimes is
> just not acceptable.
I disagree.
Generating continuous network traffic to keep something like nfs in sync is
usually a good thing. You don't want to accumulate large amounts of unsynced
data so that you have to wait for them beeing synced once you want to do
something else on the file system.
Ok, I understand your point, but the key is "sometimes". I can't
imagine such a scenario right now, but there surely are many. And,
really, I don't mean to whack the whole VFS layer because of 2 stupid
examples from the top of my head; the real point is that
- Some file systems are made for specific purposes, with specific requirements
- There's no way the VFS layer can account for every possible
variation on the requirements of a specific-purpose FS
- Then, the VFS layer should be made flexible enough so that special
purposes file systems can have their requirements fullfilled. The
specific case in point was frequency of syncing. Syncing too
frequently could be innapropriate for devices which develop wear by
mechanical stress (like floppy drives, MO etc) or substrate wear
(again, MO, flash, packet-writing-formatted CDRWs/DVDRWs). Not to
mention the energy requirements, which could impair mobile use.
- Now the question is, "how". How is the VFS supposed to be warned of
the particularities of some file system? Well, it could be by allowing
every possible tunable parameter to be tuned, something like the BSD
sysctl tunables. It could be by the means of iocntl calls. Could be.
That's how it's been traditionally done.
I find it completely unelegant.
I don't know how the Haiku VFS currently is, or how the FS Handler API
works, but if there could be any way to delegate those specialty tasks
to the FS handler itself, by allowing it to elegantly override the
defaults when appropriate and just use the defaults when it has not to
care; *that* is what I've been proposing.
You also do not need JFFS for USB memory sticks, as they have an included
controller that does all the hard work of wear balancing, erasing blocks, etc.
Not the cheap ones; not the old ones; not most of the memory card
adapters; and we should certainly NOT be constrained by 2 stupid
examples I gave from the top of my head...
If you were to use haiku with an embedded system that has flash memory directly
attached to the CPU, you probably need a flash file system, but this isn't our
target
right now. However, you could easily implement a flash file system that ignores
all
calls of sync(), or do your own vfs changes. I once used JFFS2 with some
AMD flash on a MPC60 (PPC32) cpu with Linux.
Don't you think it would be very dangerous to ignore calls to sync()?
The OS would believe it's safe to do something when it's not... How
can you guarantee FS consistency when you just can't tell sync() has
succeeded or not?
I disagree.
The FS shouldn't have to care about this. But the haiku vfs should be made
smart enough to cache access time changes, and not flush them to disk unless
there is another type of write access.
If we have any apps that periodically write data, they need to be fixed.
Access time changes is a problem Linux faces WRT syncing; it's not
what I questioned here before. My points are completely based upon
special purposes file systems and how would the VFS adapt itself to
their requirements.
I think for removeable media, using a write cache is beneficial. But the vfs
needs
to ensure that its save. Personally, I use only USB sticks that have a light
that blinks
to show if it is being used by the computer. So using write caching with 0.5
seconds
sync interval would be nice. I just wait until is stops blinking, and then
remove it.
On the other hand there are cheap and slow USB sticks that have no indicator.
Copying
files by tracker would be finished, and the cache would still be busy for a
minute to flush
all the data. I think unless someone steps up and implementes something that
allows
reinsertion to finish an aborted cach sync, we have to force synchronous
operation
for removeable media.
Well, I actually proposed just that in another email ;)
Having to always use a deskbar button, extra application etc to remove external
USB storage is tiresome, unless we make it configureable (to allow enabling
write caching),
and have it default to the easy way (i.e. wait until finished and then pull the
plug)
As Waldemar said (but here's my wording): you just can't underestimate
the capacity of a significant proportion of the end users to do
something unexpected with their computers. They WILL remove the drive
at wrong times. They just will. And now there's nothing to do with
specialty FSs, wear or whatnot; it could sport the smartest controller
and greatest journaled, self-healing FS ever; removing it at the wrong
time and having no way to restart the operation WILL corrupt the FS.
Other related posts:
