ext3 commit time
Hi, I am running the ext3 filesystem on a laptop. The default value for the commit time of ext3 seems to be 30 sec, which is too short for the HD to spin down. How can I increase this timeout ? Has anyone experineces of bad impacts in increasing this timeout to several minutes ? standard-kernel : 2.4.17 e2fsprogs version: 1.25-1 Daniel _ Daniel Faller Fakultaet fuer Physik Abt. Honerkamp Albert-Ludwigs-Universitaet Freiburg Tel.: 0761-203-5875 Fax.: 0761-203-5967 e-mail: [EMAIL PROTECTED] URL:http://webber.physik.uni-freiburg.de/~fallerd
Re: ext3 commit time
On Sat, Feb 16, 2002 at 04:38:09PM +0100, Daniel Faller wrote: Hi, I am running the ext3 filesystem on a laptop. The default value for the commit time of ext3 seems to be 30 sec, which is too short for the HD to spin down. How can I increase this timeout ? Use tune2fs (man tune2fs for usage). Has anyone experineces of bad impacts in increasing this timeout to several minutes ? I'd imagine the ill affects would be more likelyhood of losing data. You know if your hd spins down in 10 minutes, and you set the timeout to 15, it will be worse on the life of your drive, because of the constant spin up/down. Journaling filesystems really aren't all that great for laptops (maybe reiser or xfs have something to help this out, but I'm not sure). Ben -- .--===-=-==-=---==-=-. / Ben Collins--Debian GNU/Linux--WatchGuard.com \ ` [EMAIL PROTECTED] -- [EMAIL PROTECTED] ' `---=--===-=-=-=-===-==---=--=---'
Re: ext3 commit time
On Saturday 16 February 2002 17:00, Ben Collins wrote: On Sat, Feb 16, 2002 at 04:38:09PM +0100, Daniel Faller wrote: Hi, I am running the ext3 filesystem on a laptop. The default value for the commit time of ext3 seems to be 30 sec, which is too short for the HD to spin down. How can I increase this timeout ? Use tune2fs (man tune2fs for usage). The man page only mentions: -j and -J, the options for -J are size and device, but no timeout. If I really can set this with tune2fs (from the e2fsprogs package) I need to know the appropriate option. :-) Gruss Daniel _ Daniel Faller Fakultaet fuer Physik Abt. Honerkamp Albert-Ludwigs-Universitaet Freiburg Tel.: 0761-203-5875 Fax.: 0761-203-5967 e-mail: [EMAIL PROTECTED] URL:http://webber.physik.uni-freiburg.de/~fallerd
Re: ext3 commit time
Hi Daniel! On Sat, 16 Feb 2002, Daniel Faller wrote: I am running the ext3 filesystem on a laptop. The default value for the commit time of ext3 seems to be 30 sec, which is too short for the HD to spin down. How can I increase this timeout ? Has anyone experineces of bad impacts in increasing this timeout to several minutes ? standard-kernel : 2.4.17 e2fsprogs version: 1.25-1 i think newsforge has had an interview with one of the ext3 developers recently and he mentioned that this was one of the current problems with ext3. it does override any setting that prevents it from syncing the filsystem. yours martin -- [EMAIL PROTECTED] -- NO HTML MAILS PLEASE PGP/GPG encrypted and signed messages preferred pgpk6VXmwF0V0.pgp Description: PGP signature
Re: ext3 commit time
On Sat, Feb 16, 2002 at 07:25:32PM +0100, Martin Wuertele wrote: Hi Daniel! On Sat, 16 Feb 2002, Daniel Faller wrote: I am running the ext3 filesystem on a laptop. The default value for the commit time of ext3 seems to be 30 sec, which is too short for the HD to spin down. How can I increase this timeout ? Has anyone experineces of bad impacts in increasing this timeout to several minutes ? standard-kernel : 2.4.17 e2fsprogs version: 1.25-1 i think newsforge has had an interview with one of the ext3 developers recently and he mentioned that this was one of the current problems with ext3. it does override any setting that prevents it from syncing the filsystem. No, I believe the article stated he had an ugly patch that fixed the frequent write problem, but that it had some unacceptable side effects like making fsync() a noop, and therefore the patch is not published. I recall reading an interesting interview with Theo de Radt (OpenBSD) where he argued against journaled file systems, saying they had solved issues of data integrity in a much safer way with better performance. I don't know how much merit there is to his argument, but it'd be interesting to see some comparison tests, including ones testing for exceptional conditions and data integrity as well as pure performance. -- Eric G. Miller egm2@jps.net
