2gb vs 4gb RAM

[levi]

What was wrong with just doing...?

alias cpa='cp $@; sync'

Whats the benefit of declaring a function then calling that function over just doing it?

 

[ible]

i don't think functions can be defined in aliases, at least not in bash. but you can just define the function:

function cpa() {
 cp $@
 echo 'asdfasdfasdf'
}

just kidding, use sync instead of echo...

 

[levi]

Yeah, I didn't test if functions could be defined there because I still don't really understand why you'd want to.

 

[klapse]

well i tried the alias but i can't use $@ in an alias

 

[Mr_Loon]

Nevertheless most people have preordered 4gb and there is the question whether the 2gb units will be produced at all.

It would help a lot of people if this could be decided.

 

[WizardStan]

well i tried the alias but i can't use $@ in an alias

Yeah, alias doesn't do any interpretation, it literally just replaces what you type with the alias. so "cpa foo bar" gets replaced with "cp $@; sync foo bar"
A function is the way to go, exactly as you did it (functions can be defined in an alias). Or even just define the function without the alias as ible did.

 

[Grench]

OK - so what line can I add to which config file to have the file manager in Cinnamon DE on Debian keep the 'writing' dialog open on all removable media devices until the write/sync is complete AND not sit there doing nothing for 5-10 minutes mulling it over before writing?

 

[WizardStan]

OK - so what line can I add to which config file to have the file manager in Cinnamon DE on Debian keep the 'writing' dialog open on all removable media devices until the write/sync is complete AND not sit there doing nothing for 5-10 minutes mulling it over before writing?

You can't, nor should you. The progress bar is just doing what the kernel says, and the kernel "finishes" the unsynced copy quickly: all you'd get is a progress bar zip across to 100% and then sit there for an indeterminate length of time while the sync finishes. If this is an internal disk there's no need to worry about syncing. If it's a USB drive and you want to drag, drop, and go then you should be properly ejecting it anyway. If you want a progress bar of some sort I wasn't able to find one, but you can see how many requests are left to be written with the block stats file (in_flight is what you want: when it's 0 there's nothing left to write). You could write a script that tracks this number and estimates how long it'll be to reach zero.
If this is something you do regularly with the same USB drive you could try adding an fstab entry for the drive with the "sync" option, that'll give you the progress bar you want, but it'll be exceptionally slower than doing a copy/sync. At the very least you could add the "flush" option so you're not waiting for a few minutes before it even starts: flush causes it to start syncing almost immediately, if possible.

 

[Grench]

You can't, nor should you. The progress bar is just doing what the kernel says, and the kernel "finishes" the unsynced copy quickly: all you'd get is a progress bar zip across to 100% and then sit there for an indeterminate length of time while the sync finishes. If this is an internal disk there's no need to worry about syncing. If it's a USB drive and you want to drag, drop, and go then you should be properly ejecting it anyway. If you want a progress bar of some sort I wasn't able to find one, but you can see how many requests are left to be written with the block stats file (in_flight is what you want: when it's 0 there's nothing left to write). You could write a script that tracks this number and estimates how long it'll be to reach zero.
If this is something you do regularly with the same USB drive you could try adding an fstab entry for the drive with the "sync" option, that'll give you the progress bar you want, but it'll be exceptionally slower than doing a copy/sync. At the very least you could add the "flush" option so you're not waiting for a few minutes before it even starts: flush causes it to start syncing almost immediately, if possible.

I've seen that answer in many places across various Linux help forums and find it unacceptable, unintuitive, and generally bad for user acceptance.

When I copy and paste a file, I expect the dialog box to tell me when it is -done-. Not just when it is done copying it to RAM.

When there is a progress bar scampering across I expect that to be for the write, not the read. Alternatively TWO progress bars would be acceptable, one for the write and one for the read.

When I copy and paste a file, I expect it to start writing immediately. Yes, keep reading and filling the cache too. The current scenario where it can be an indefinite amount of time between the read and when the system thinks about maybe starting the write, I find that unacceptable.

The cache now write some arbitrary time later philosophy may work well in a server setting - I can even see it as beneficial.

In a desktop/workstation setup, though, the #1 most important thing that the OS/DE can do at any given point in time is what the user (human at keyboard - most expensive component) told it to do. Everything else can be cached. But when that write command is coming from the fleshy construct between the keyboard and monitor, just do it. Linux needs a user time optimization Vs computer time optimization settings option.

 

[levi]

Yeah, removable media is the only fly in the ointment really. In terms of 'done' it's done when the bar reaches the end, in that you can start doing more fs-based stuff immediately without it having to time share and wear out the head stepper motor. Sure, just afterwards the caches are rather full which will limit apparent performance if you're talking to slow media.

The flush mount option seems almost ideal to me for removable drives. I wasn't aware of that. Of course you'll still need to unmount, just as you are meant to do on windows (at least if it's a mass storage device). In most modern file managers you just need to right click the drive icon in the list of mount points towards the left somewhere to bring up the menu containing the unmount option. FWIW I've never seen the system not free the caches for minutes at a time; if I leave it just ten seconds or so before unmounting it's so quick I assume it's already written out the stuff, and I don't use the flush option presently.

 

[Grench]

Of course you'll still need to unmount, just as you are meant to do on windows (at least if it's a mass storage device). In most modern file managers you just need to right click the drive icon in the list of mount points towards the left somewhere to bring up the menu containing the unmount option.

Yes, I get/understand/grok unmounting the media prior to removal. I'm just annoyed that my Linux box can sit unused & idle for 20 minutes after a file copy, then when I tell it to umount the usb, that is when it -starts- writing and proceeds to happily spool data off to the USB for the next 1 to 100+ minutes with no indication of how long this is going to take.

The user shouldn't have to guess how much data is pending to be written to a removable device. The GUI file managers on most Linux DE environments show file copy progress in a separate window and you can merrily go about adding items to that queue. From the file manager's perspective, though, when data has been read and written to the OS pipe for the target, the task is 'done'.

Writes to removable devices on non-server platforms should be an immediate and high priority process - keep that write buffer full until done. If write caching is going to be ubiquitous, then there needs to be something at the UI level showing pending writes and estimated time to completion for every cached device. Preferably this should be shown on the distribution's DEs included file management GUI.

If you're working from a remote command line, cached writes mean you can use the same prompt and keep doing stuff while the OS sorts out the rest - great. If you're working from a local GUI doing normal desktop user tasks, though, not so great.

Pyra use case example:
Two people (Jack & Jill) take pictures using real cameras with SD cards at a wedding and want to directly share/swap photos.
Jack's SD card goes in the left slot.
Jill's SD card goes in the right slot.
Using the file manager on the UI, Jill (it is her Pyra) rubber bands Jack's photos, right clicks copy, goes to her card, creates a Jack directory, opens it, then right clicks paste into it. A dialog box pops up talking about the process. She then goes up a directory on her card, rubber bands everything but the Jack directory, right clicks copy, goes to Jack's card, creates a Jill directory, opens it then right clicks paste into it.
Five minutes later the Pyra's FM says it is done.
Jill tells the card to eject/unmount.
The writes then start to both cards, drive lights flash like mad again, and the Pyra appears 'locked up'.
If Jill is a Linux power user she knows that the device is flushing the cache and doing the actual work that she had asked it to do.
If Jill is a normal human, she's confused, annoyed and suspects that the Pyra is eating all of her wedding photos.
Worst case scenario she panics, ejects the half-written SD media (possibly bricking the cards) or hard power cycles the Pyra (possibly bricking the cards).

 

[levi]

No modern linux system should lock up just because it's writing to media. That's a very old behaviour I last saw on non-multitasking kernels with non-DMA disk transfers. But yeah, if you mount with -o flush that should pretty much fix that use case, no?

 

[wismerhill]

Just mount your removable medias with the sync option, from the manpage of mount, that option is honored by ext[23] fat/vfat and ufs. Your removabnle medias are probably vfat, so with that option all IO will be done synchronously.

There is probably some configuration file where you can add options four automounts, but that is dependant on what service is actually doing the mounting.

 

[levi]

Yeah, but I wouldn't advise using sync on flash based devices. It's much more efficient and promotes less write cycles if you can buffer a whole block size before writing. I've not tested it, but I hope that flush option is a happy medium between letting caches hold data for extended periods and immediately committing any changes.

 

[Grench]

No modern linux system should lock up just because it's writing to media. That's a very old behaviour I last saw on non-multitasking kernels with non-DMA disk transfers. But yeah, if you mount with -o flush that should pretty much fix that use case, no?

Since there is only a static "Do not remove device" message during this process which stays on-screen and static, and the process is indeterminate and the user is directly waiting on that action to perform their next human action, it may as well be locked up.

Yeah, but I wouldn't advise using sync on flash based devices. It's much more efficient and promotes less write cycles if you can buffer a whole block size before writing. I've not tested it, but I hope that flush option is a happy medium between letting caches hold data for extended periods and immediately committing any changes.

So where would I add -o flush to which configuration file to automatically mount with -o flush any removable media device? I.e. any device not present at boot.

 

[Letalis Sonus]

So where would I add -o flush to which configuration file to automatically mount with -o flush any removable media device? I.e. any device not present at boot.

Create an udev rule. You have a lot more options available to decide when to apply it as well.

 

[WizardStan]

I've seen that answer in many places across various Linux help forums and find it unacceptable, unintuitive, and generally bad for user acceptance.

That's unfortunately how it works. Everywhere. Windows and Mac too. At least with linux you've got the option of turning on the flush or sync options, and you can see the remaining requests ticking down to zero.

 

[levi]

Your automounter might actually already be a udev rule, it seems. Check in /etc/udev/rules.d/ (mine is empty fwiw). If it is already a rule file in there you should be able to modify it.

 

[ible]

i guess if you have a choice, you should definitely go against the universally recommended way of doing it...

 

[Silent-Hunter]

I don't wanna force it to sync early, necessarily. I'd just like to have a true progress bar somewhere I can see when it's actually done writing.