[opensuse] when is data physically written to disk (Reiserfs)?
Hello I'd like to know when data that should be written is really written physically to the disk. I use OS 12.3, Reiserfs (with encrypted LV for /home, /root, /swap, on 1 drive and separate encrypted drive outside LVM) Several times after switching off without properly shutting down (after power fail) and rebooting I noticed that there were many systemd-fsck[720]: Trans replayed:... Trans replayed: mountid... even when the computer was not doing anything before the switch-off occurred. Like today: the computer was "on" during the night, but without doing anything, in the early morning the electricity was cut off and so I had to reboot and I got hundreds of "replay"-messages... I thought, data would be written to the disk physically and definitively at least in moments when the computer has nothing else to do, but how comes that after hours of being idle there still remains so much to replay? Is this normal? Should I check some settings? Thanks for explanation or hints... Daniel -- Daniel Bauer photographer Basel Barcelona http://www.daniel-bauer.com room in Barcelona: https://www.airbnb.es/rooms/2416137 -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
On 2014-10-23 11:27, Daniel Bauer wrote:
Is this normal?
I think it is normal. Your data was probably written ages ago, but many files are "open". A lot of them are things used by the system, not "you". -- Cheers / Saludos, Carlos E. R. (from 13.1 x86_64 "Bottle" at Telcontar)
On 10/23/2014 05:27 AM, Daniel Bauer wrote:
Is this normal? Should I check some settings?
Thanks for explanation or hints...
The short answer is that ReiserFS is a journaling file system. Journaling is a mechanism that helps file systems survive crashes. Previously, file systems could not guarantee to have written both data and structure to the physical disk in the event of a crash. This is a good analysis though rather technically abstract http://research.cs.wisc.edu/wind/Publications/sba-usenix05.pdf caching, delayed write and other mechanisms speed the computer's performance, but a at a cost in the event of a disaster. http://www.ibm.com/developerworks/library/l-journaling-filesystems/ <quote> In recent history, journaling file systems were viewed as an oddity and thought of primarily in terms of research. But today, a journaling file system (ext3) is the default in Linux®. Discover the ideas behind journaling file systems, and learn how they provide better integrity in the face of a power failure or system crash. Learn about the various journaling file systems in use today, and peek into the next generation of journaling file systems. .... In general, journaling file systems avoid file system corruption by maintaining a journal. The journal is a special file that logs the changes destined for the file system in a circular buffer. At periodic intervals, the journal is committed to the file system. If a crash occurs, the journal can be used as a checkpoint to recover unsaved information and avoid corrupting file system metadata. </quote> That's from 2008 Also look at man tunefs.reiserfs And of course http://en.wikipedia.org/wiki/Journaling_file_system Also worth reading http://lwn.net/Articles/283161/ http://www.linuxjournal.com/article/4466 -- We know not where our dreams will take us, but we can probably see quite clearly where we'll go without them. - Marilyn Grey -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
Am 23.10.2014 um 15:10 schrieb Anton Aylward:
On 10/23/2014 05:27 AM, Daniel Bauer wrote:
Is this normal? Should I check some settings?
Thanks for explanation or hints...
The short answer is that ReiserFS is a journaling file system. Journaling is a mechanism that helps file systems survive crashes.
Previously, file systems could not guarantee to have written both data and structure to the physical disk in the event of a crash.
This is a good analysis though rather technically abstract http://research.cs.wisc.edu/wind/Publications/sba-usenix05.pdf
caching, delayed write and other mechanisms speed the computer's performance, but a at a cost in the event of a disaster.
http://www.ibm.com/developerworks/library/l-journaling-filesystems/ ...
Also look at man tunefs.reiserfs
And of course http://en.wikipedia.org/wiki/Journaling_file_system
Also worth reading http://lwn.net/Articles/283161/ http://www.linuxjournal.com/article/4466
Uff, I don't want to get a file system specialist :-) But anyway, thanks a lot! The answer to my question was found on your link on the IBM site under ReiserFS: "The commit policy depends on the journal size but is based on the number of blocks to commit." This makes all clear to me. I thought it depended on time and idle states, but as it is size and numbers it's only logical that there may be a lot to commit even after a long time of doing nothing... Thanks and regards from Barcelona. Daniel -- Daniel Bauer photographer Basel Barcelona http://www.daniel-bauer.com room in Barcelona: https://www.airbnb.es/rooms/2416137 -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
On 10/23/2014 08:18 PM, Daniel Bauer wrote:
may be a lot to commit even after a long time of doing nothing...
- might be positive to made habit of giving Command, as root, x3 , three times : # sync sync sync , when about to leave Keyboard :) ............ regards -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
On 10/23/2014 01:42 PM, ellanios82 wrote:
On 10/23/2014 08:18 PM, Daniel Bauer wrote:
may be a lot to commit even after a long time of doing nothing...
- might be positive to made habit of giving Command, as root, x3 , three times :
# sync sync sync
, when about to leave Keyboard :)
Hmmmm. I think there's a case of "yes it used to be but we changed all that" here. I'm not sure why. The test for this is to do the three syncs then pull the plug on the system without a clean shutdown. BTDT (though not by intent) and found that there is _still_ the restoration on reboot. I don't know why. Yes I would expect the sync to clear the logs, but apparently not. I had always thought 'sync' to be efficacious. On the other hand a clean unmount does. All that being said, there are options to open files with O_SYNC as well as mounting file systems in synchronous mode. There is also the option of mounting file systems with making directory and other structural metadata synchronous. See 'man mount' and 'man chattr' -- The very essence of leadership is its purpose. And the purpose of leadership is to accomplish a task. That is what leadership does--and what it does is more important than what it is or how it works. - Colonel Dandridge M. Malone -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
Am 23/10/14 um 11:27 schrieb Daniel Bauer:
Hello
Hello, [...]
even when the computer was not doing anything before the switch-off occurred. Like today: the computer was "on" during the night, but without doing anything, in the early morning the electricity was cut off and so I had to reboot and I got hundreds of "replay"-messages... [...]
Others gave answers to your question regarding filesystem. May I suggest something different. There are relatively cheap USV like this one: http://www.apc.com/products/resource/include/techspec_index.cfm?base_sku=BE700G-UK&total_watts=200 I have the European version: http://www.apc.com/products/resource/include/techspec_index.cfm?base_sku=BE700G-GR&total_watts=200 and there are other versions for different purposes and countries and different running time. This thing "saved my day" several times. It does not cost to much: http://geizhals.at/apc-back-ups-es-700va-steckdosenleiste-be700g-gr-a484963.... Take a software like http://www.apcupsd.com/ and your computer will shutdown even if you are away or sleeping. If configured correctly you will never have filesystem replays because of power loss. ;-) Of course: larger machines need larger USVs... BR Markus P.S.: I am not working for any of these companies. -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
participants (5)
-
Anton Aylward -
Carlos E. R. -
Daniel Bauer -
ellanios82 -
MarkusGMX