| 1 |
On Dec 18, 2007 6:40 PM, Hemmann, Volker Armin |
| 2 |
<volker.armin.hemmann@××××××××××××.de> wrote: |
| 3 |
> |
| 4 |
> On Mittwoch, 19. Dezember 2007, Canek Peláez Valdés wrote: |
| 5 |
> > On Dec 18, 2007 2:56 PM, Sergey Kobzar <tod.zullu@×××××.com> wrote: |
| 6 |
> > > Hi guys, |
| 7 |
> > |
| 8 |
> > [...] |
| 9 |
> > |
| 10 |
> > > - ext3 looks slow some time |
| 11 |
> > |
| 12 |
> > The defaults are slow, but you can change them and make it OK. Not |
| 13 |
> > super fast, but OK. Check out |
| 14 |
> > /usr/src/linux/Documentation/filesystems/ext3.txt, and tweak the |
| 15 |
> > obvious options. |
| 16 |
> > |
| 17 |
> > data=writeback and commit=300 in particular works fine in my VAIO |
| 18 |
> > laptop. And we're talking about laptops, so a sudden loss of power is |
| 19 |
> > not something that could happen at any moment. |
| 20 |
> |
| 21 |
> there is still 'didn't resume correctly' or 'froze and had to hit reset' which |
| 22 |
> is as harmfull as power loss. |
| 23 |
|
| 24 |
It's been *months* since I had any trouble with suspend/resume with my |
| 25 |
laptop; but if you are really that paranoid you can always edit |
| 26 |
|
| 27 |
/usr/lib/hal/scripts/linux/hal-system-power-suspend-linux and |
| 28 |
/usr/lib/hal/scripts/linux/hal-system-power-hibernate-linux |
| 29 |
|
| 30 |
and do a 'sync' before the suspend; problem solved. If you use |
| 31 |
gnome-power-manager (or the HAL-aware KDE equivalent) to |
| 32 |
suspend/resume, of course; if you do it by other means I'm sure you |
| 33 |
can put the sync command in some other place. |
| 34 |
|
| 35 |
(And actually, I'm pretty sure HAL does the sync by itself; it would |
| 36 |
be idiotic not to do it.) |
| 37 |
|
| 38 |
And BTW, AFAIK the same thing happens with *all* the journaled |
| 39 |
filesystems, but the data=ordered and commit=5 as default in ext3 is |
| 40 |
because the developers are more concerned with data integrity. |
| 41 |
Journaled filesystems are not meant to guarantee data integrity; they |
| 42 |
guarantee *filesystem* integrity. Meaning: you can lost some of your |
| 43 |
work, but the filesystem will be OK and no fsck is required (in the |
| 44 |
old days that could be *REALLY* slow). |
| 45 |
|
| 46 |
With ext3 using data=writeback, commit=300 and you get a failed resume |
| 47 |
and you (or HAL) did't sync before resuming, you at mos lost five |
| 48 |
minutes of work; everything else will be a-OK. Which is the point of |
| 49 |
the journaled filesystems, of course. |
| 50 |
|
| 51 |
But that's only my advice: years ago I lost a chapter of my BS thesis |
| 52 |
thanks to ReiserFS. I'm sure they got way better (because a lot of |
| 53 |
folks use it), but if there is something you can say about ext2/ext3, |
| 54 |
is that they are the *most* stable filesystems available. That's the |
| 55 |
reason of the "slow" defaults (data=ordered and commit=5); the |
| 56 |
developers guarantee that, out of the box, ext3 will guarantee |
| 57 |
filesystem integrity (as all the journaled filesystems do) AND it will |
| 58 |
protect your data at all cost. With data=writeback and commit=300, |
| 59 |
ext3 behaves as all the other journaled filesystems (AFAIK; I haven't |
| 60 |
checked the progress in filesystems in a while): it only guarantees |
| 61 |
the filesystem integrity, meaning you *could* (it would be difficult |
| 62 |
anyway) loss 5 minutes of work. |
| 63 |
|
| 64 |
See your options; but I'm using Linux since 1996, and Gentoo since |
| 65 |
2003, and I have *never* loss data with ext2 and ext3. With ext3 being |
| 66 |
journaled, of course. And I use suspend all the time in my laptop. |
| 67 |
|
| 68 |
In my desktop I use the ext3 default options; my UPS is old and is not |
| 69 |
working that well, and besides my desktop uses SATA and is *stupidly* |
| 70 |
fast, so you don't see the performance penalty. |
| 71 |
|
| 72 |
Good luck; let us know what you decide. |
| 73 |
-- |
| 74 |
Canek Peláez Valdés |
| 75 |
Facultad de Ciencias, UNAM |
Archives