On Mittwoch, 19. Dezember 2007, Canek Peláez Valdés wrote: > On Dec 18, 2007 6:40 PM, Hemmann, Volker Armin > > <[EMAIL PROTECTED]> wrote: > > On Mittwoch, 19. Dezember 2007, Canek Peláez Valdés wrote: > > > On Dec 18, 2007 2:56 PM, Sergey Kobzar <[EMAIL PROTECTED]> wrote: > > > > Hi guys, > > > > > > [...] > > > > > > > - ext3 looks slow some time > > > > > > The defaults are slow, but you can change them and make it OK. Not > > > super fast, but OK. Check out > > > /usr/src/linux/Documentation/filesystems/ext3.txt, and tweak the > > > obvious options. > > > > > > data=writeback and commit=300 in particular works fine in my VAIO > > > laptop. And we're talking about laptops, so a sudden loss of power is > > > not something that could happen at any moment. > > > > there is still 'didn't resume correctly' or 'froze and had to hit reset' > > which is as harmfull as power loss. > > It's been *months* since I had any trouble with suspend/resume with my > laptop; but if you are really that paranoid you can always edit > > /usr/lib/hal/scripts/linux/hal-system-power-suspend-linux and > /usr/lib/hal/scripts/linux/hal-system-power-hibernate-linux > > and do a 'sync' before the suspend; problem solved. If you use > gnome-power-manager (or the HAL-aware KDE equivalent) to > suspend/resume, of course; if you do it by other means I'm sure you > can put the sync command in some other place.
that won't help you if the box dies because battery runs dry in s2ram or when the crash happens while resuming and some stuff has been read and written. > > (And actually, I'm pretty sure HAL does the sync by itself; it would > be idiotic not to do it.) sync&& echo mem /sys/power/state you don't need hal for stuff like that. In fact, you don't need hal at all. And maybe you should rethink your dependency on a 'tool' that is rewritten every odd month. You also might find this interessting: http://blog.cardoe.com/archives/2007/12/06/no-longer-maintaining-gentoos-hal/ just read the links. But you should have a barf bag ready. > > And BTW, AFAIK the same thing happens with *all* the journaled > filesystems, but the data=ordered and commit=5 as default in ext3 is > because the developers are more concerned with data integrity. > Journaled filesystems are not meant to guarantee data integrity; they > guarantee *filesystem* integrity. Meaning: you can lost some of your > work, but the filesystem will be OK and no fsck is required (in the > old days that could be *REALLY* slow). I know that. I am not a newbie. But XFS is especially bad at keeping data. > But that's only my advice: years ago I lost a chapter of my BS thesis > thanks to ReiserFS. I'm sure they got way better (because a lot of > folks use it), but if there is something you can say about ext2/ext3, > is that they are the *most* stable filesystems available. That's the > reason of the "slow" defaults (data=ordered and commit=5); the > developers guarantee that, out of the box, ext3 will guarantee > filesystem integrity (as all the journaled filesystems do) AND it will > protect your data at all cost. With data=writeback and commit=300, > ext3 behaves as all the other journaled filesystems (AFAIK; I haven't > checked the progress in filesystems in a while): it only guarantees > the filesystem integrity, meaning you *could* (it would be difficult > anyway) loss 5 minutes of work. yeah, well, that explains all the trouble people had with ext3.... > > See your options; but I'm using Linux since 1996, and Gentoo since > 2003, and I have *never* loss data with ext2 and ext3. With ext3 being > journaled, of course. And I use suspend all the time in my laptop. well, I am using linux since kernel 2.2.10 and gentoo since 1.0 And I have seen data loss caused by ext2 and ext3. I also see the 'bug of the month' for ext3 on lkml (and the 'bug of the week' of xfs) People always remember their 'reiserfs' horror stories, but tend to forget ext3 horrors - and a lot of the most vocal ones don't even realize that reiserfs in early 2.4 (where most of the horror stories originate) was not bad - it just was broken by the constant vm-changes. And some devs not bothering cleaning up the mess (yes Rik, Andrea and Linus, I am looking at you ...). -- [EMAIL PROTECTED] mailing list
