[EMAIL PROTECTED] wrote:
>Hey guys (are there any girls on this list - hmm)
>Which filesystem would you recommend for a biggish (10 gig) partition ?
At
>the moment I'm using Ext2fs and I really have to use something else,
it's
>just way to slow. So should i use Reiser or Ext3fs ? Or is there maybe
>another fs I can use ?
In what areas of use does the Ext2 FS on your 10GB drive seem "way to
slow"?
When a file transfer starts my cpu jumps to 100% and my pc almost
freezes up
for a while before i can work again. It's horribly slow on read and
write requests.
While playing a movie and working on a xterm the cursor stops responding
every now
and then.
Transferring a file from one folder to another?
yes
With only one disk you're copying from disk, to MB and writing back to
the same disk - not the speediest of disk operations normally. It would
help to know if this partition contains all of Debian or if it is just
one mount like /home and if the rest of Debian is on the same disk or
another disk
All of debian on 1 partition - I know this is not recommended, but I'm
not
in the mood to create a bunch of partitions and try and manage that.
Reading files off the disk?
yes
Linux nicely pre-fetches data beyond your read request anticipating that
you are going to need that data, thus speeding disk reads by reducing
the need to move the head around. Severely fragmented files may not have
their data within that read-ahead section and miss out on that potential
performance gain.
I though ext2fs didn't fragment ? Seems like some of the linux-boys here
at work don't know what they're talking about ;-).
Files that are always appended to (like some tar
files, directories that keep getting new entries, or system logs) are
very likely to fragment. Files that are re-written get a clean slate and
are not fragmented. Once the kernel reads something it keeps it in
memory if possible since that is much faster. If you don't have much
free memory, you are missing out on that gain as well.
I've got 800 MB's of ram so i think it's not a memory problem
I don't know if
the Resier FS handles fragmentation of appended files better, but any
file system will appear to work faster on cached data if you have oodles
of memory.
Some other situation?
Maybe the disk/controller isn't using DMA? What type of disk is it?
It's a seagate Baracuda 80 gig, so it does use DMA. Are there any
specific drivers
I should load for DMA to work properly ?
I haven't used much of anything outside of ext*, so I can't give an
experiance based comment on Reiser. It's suppose to be pretty fast and
good at handling lots of small files and directories.
Can you define small file for me ? Small as in < 5k / < 10 k
?
The place where ext3 orders of magnitude faster than ext2 is when you
boot up after an improper shutdown/unmount. ext3 (which is basically
ext2 with journaling) can safely skip fsck for the most part. Ext2 you
get to sit there watching the file systems scan away. The bigger your
hard disk, the longer you'll sit and the faster ext3 would seem. :) In
other cases, because ext3 is writing it's journal to a disk every few
seconds, it could be a little slower. Since most systems aren't normally
under intense I/O, this is usually unnoticable. You do have the option
of storing the journal to a different disk.
So what you're saying is that I'm actually using the faster filesystem ?
(Barring disk checking now - which doesn't really matter anyway, it's
not like that happens every day)
From what I've read I'm beginning to think I've got some driver problem.
Ok, I've hit the end of any helpfull thought on the subject, now for
some related ponderings:
You've been very helpfull thanx dude.
Jacob
Sorry for the bold italics, but I was getting sick of indenting with >
line by line. Lotus Notes is probably the most stupid email clients
around when it comes to that
***************
Any views expressed in this message are those of the individual sender, and
Sanlam accepts no liability therefore, except where the sender specifically
states them to be those of Sanlam.
Enige sienswyses of stellings wat in hierdie boodskap uitgedruk word is dié
van die individuele afsender, en Sanlam aanvaar geen aanspreeklikheid
daarvoor nie, behalwe waar die afsender uitdruklik vermeld dat dit dié van
Sanlam is.
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]