Is it recommended to use the sync option for removable devices? Wouldn't it help lessen the chance of data loss in the event the device is removed before unmounting?

What about it's use on internal hard drives?

If I may counter that with two things you could research yourself: 0) what does 'man mount' say about the meaning of the option "sync" and 1) can you find out if "umount" does a sync() before unmounting a device?

Recommended, not specially, but usable if you fear a hard disconnection, yes, you can.

We dont use it about drives, but partitions...

unSpawn, I do understand what you are trying to do here ... to teach me to teach myself. Commendable, and I agree. However, I have read documentation, and I think my understanding of sync is on par. But just for the heck of it:
0. the sync option flushes the data stream directly to the device, rather than hold it in the write buffer. This allows faster overall performance, but could potentially result in corruption if the device is disconnected before the buffer is flushed.
1. Yes. umount performs a sync. It would be illogical NOT to sync before removing the device, yes?

However, there are times when I would like to be able to write to a diskette, then temporarily remove the disk for testing (read testing) on another machine, without having to unmount first. I know this goes somewhat against Linux ...

P.S. I like the way you started with 0, instead of 1. Very computerized of you!

Ah, why didn't you say that in the first place? You want to deliberately fsck up things!
I'd say that's cool as long as nothing requires to read from or write to the fd while it's removed.
In any case fds are so cheap you could simply test this, right?

Heh, I would go as far as to say I'm trying to kill my data ...

But I suppose what I want to know is if there's a best practice for sync. For instance, there appears to be a balance between performance and data safety.

So, if my /home directory is mounted default, and some of its data is buffered, then I lose power, that file system has higher potential for corruption. But if the partition is mounted with sync, then that potential is lessened. On the flip side, performance on that partition is also decreased.

Here's one I found ... apparently flash technology life can be lessened if you use sync, due to the write accesses. But a flash drive could be treated just like a floppy, right? If it was mounted sync, could it be removed temporarily? On the other hand, USB tech is typically auto-recognized by Linux these days, so that could be a hassle.

By now now you've tossed all sorts of incomparable hardware examples in the ring just to arrive at your conclusion that "if it works on device Y it should also work on device Z". I could try and support the Dark Side by saying I Find Your Lack Of Faith Disturbing and stuff and talk about buffers, journalling metadata plus data, dirty flags and such I think it won't matter since I think you're gonna try anyway ;-p So.
Quench your thirst for knowledge: experiment with it to experience it :-]

No. You've got me all wrong, Master. You assume to much. I am your Padewan. I desire to learn. I'm not assuming that hard drives, flash drives, and floppy drives should be handled in the same manner. In fact, I believe quite opposite.

Again, I desire to understand best practices, why do we do it the way we do it? Other than performance, why would you mount hard drives async? Why would you mount floppies sync? Do file systems themselves play a role? What is this turtle thing we ride through the vastness of the universe?

Master, teach me. Show me the ways of this force called Linux. Show me how to use my powers to their fullest potential ... Learn me the ways of the Linux Guru.

Heh. No need to go all Jedi on me. I'm certainly no guru.

Performance *is* the reason, but a more suitable term IMHO would be cost so the question becomes: "Why are I/O ops expensive?"
I suggest getting a copy of O'Reilly's "Understanding the Linux Kernel", 3rd Edition (shouldn't be hard to find) and start in the middle with chapter 14 "Block Device Drivers" and read on to section 14.3. "The I/O Scheduler". Then back to 13.4.3.2. "Interrupt mode" which should lead to 4.1. "The Role of Interrupt Signals" and on to the end of chapter 4. Then on to 10.2. "System Call Handler and Service Routines". If that doesn't help make things any clearer just say the word.

... And I suppose you think this will take me more than an hour to read, so you think you've heard the last from me ... for now? Muhahaha! I'll be back in 5 minutes!

It isn't about speed?

Uh. OK. Aren't you done reading yet?

Funny ...

Dern thing is, I haven't had time to run to the book store for the book. Besides, the assignment you gave me is probably worth a month of reading ...

I found it on-line and so can you. Else drop me an e-mail.


Hell no, about half an hour, gotta concentrate though ;-p
Again pages/s ain't the thing unless you're one of them LKML guys.
A discussion would be cool. Realise, not tutoring you, I am, OK?

Since you haven't found the time to read yet lets see if I can summarize it a bit for you. Processes live between the CPU and registers (top, bottom half), and that's all nice since it's all low latency locations we're talking about, and since the kernel manages what runs (that's basically what the kernel does: scheduling) it can (UP: seemingly) run many processes at the same time. In short: whatever the kernel does itself *is* asynchronous by design. The "problem" comes when the kernel needs to start an application (read disk to load process image, populate stack) or write out changes to disk. It queues data to be written and issues a write request to the Virtual File System and waits for that process to complete (meanwhile doing something else of course). Writing isn't simply copying data from a memory page to disk sector: the VFS drives the Generic Block Layer (to figure out the files metadata, decrease or increase in size etc, etc *before* actually writing data), then writing data is done by the bottom-most element in this stack: the block device driver (which "talks" to the hardware with hardware requests). While writing the process that needs the write must wait until the write is completed and can't do anything else. Also if two processes want to write to the same file only one single process *can* write to that file (else you get corruption), so unless you can queue that request you'll be blocking that process too. Writes are expensive because data transitions between fast in-kernel structures and relatively slow physical media, because there needs to be set up a lot more processing before the actual write can be done (compared to reads) and because it blocks a process from doing anything else. Now imagine all of that having to respect O_SYNC as well... I hope you get the idea.


* Anyone having their own (rather than linkage) better description or explanation: BMG.