Discussion:
when is data physically written to disk (Reiserfs)?
(too old to reply)
Daniel Bauer
2014-10-23 09:27:40 UTC
Permalink
Raw Message
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+***@opensuse.org
To contact the owner, e-mail: opensuse+***@opensuse.org
Carlos E. R.
2014-10-23 13:00:29 UTC
Permalink
Raw Message
Post by Daniel Bauer
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)
Anton Aylward
2014-10-23 13:10:26 UTC
Permalink
Raw Message
Post by Daniel Bauer
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+***@opensuse.org
To contact the owner, e-mail: opensuse+***@opensuse.org
Daniel Bauer
2014-10-23 17:18:28 UTC
Permalink
Raw Message
Post by Anton Aylward
Post by Daniel Bauer
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/
...
Post by Anton Aylward
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+***@opensuse.org
To contact the owner, e-mail: opensuse+***@opensuse.org
ellanios82
2014-10-23 17:42:28 UTC
Permalink
Raw Message
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+***@opensuse.org
To contact the owner, e-mail: opensuse+***@opensuse.org
Anton Aylward
2014-10-23 19:42:40 UTC
Permalink
Raw Message
Post by ellanios82
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 ,
# 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+***@opensuse.org
To contact the owner, e-mail: opensuse+***@opensuse.org
MarkusGMX
2014-10-23 19:40:03 UTC
Permalink
Raw Message
Post by Daniel Bauer
Hello
Hello,

[...]
Post by Daniel Bauer
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.html

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+***@opensuse.org
To contact the owner, e-mail: opensuse+***@opensuse.org
Loading...