[ale] Ubuntu Linux Defrag EXT4
Ron Frazier
atllinuxenthinfo at c3energy.com
Mon Sep 13 12:03:07 EDT 2010
Michael,
Sorry your original email crashed. Thanks for this info. That looks very
interesting, and I'm going to save the link for later examination. I don't
have the luxury of using multiple partitions / drives on the computers I
use, however, it sounds like a great idea. You seem to be very
knowledgeable, so I'm coming to you if I have more serious questions on the
topic. 8-)
Ron
At 9/13/2010 12:29 AM -0400, you wrote:
>On Sat, Sep 11, 2010 at 10:01 PM, Ron Frazier
><<mailto:atllinuxenthinfo at c3energy.com>atllinuxenthinfo at c3energy.com> wrote:
>I am interested in what everyone thinks as to the need for defrag on EXT4
>in Linux vs the need for it with NTFS and Windows.
>
>
>I had written a fairly lengthy post on this only to have it eaten before I
>hit "Send". Grr.
>
>A good place to start reading is the Wikipedia article on filesystem
>fragmentation
>(<http://en.wikipedia.org/wiki/File_system_fragmentation>http://en.wikipedia.org/wiki/File_system_fragmentation)
>which provides a good overview of the subject. Like anything on
>Wikipedia, you can spend hours upon hours reading there.
>
>Without going to a great deal of effort (we just got back from Toledo and
>I am about ready to have a long, long sleep), operating systems such as
>DOS and Windows require filesystem defragmentation as a matter of routine
>operation. The problem could be mitigated somewhat if different types of
>files were on different filesystems (e.g., if C:\, C:\Windows, C:\Users,
>C:\Program Files and C:\Program Files (x86) were all their own
>partitions), because then updates to the operating system or user profiles
>would have no effect on each other. This is one reason why a UNIX system
>with multiple partitions does not suffer (as much) from the symptoms of
>file fragmentation. Furthermore, if you can put filesystems that are
>likely to suffer a great deal of fragmentation on their own drives, you
>can reduce the symptoms even further.
>
>I've never even thought to check fragmentation on my drives at home, nor
>on the small business servers that I run; filesystem I/O is not a problem
>on my systems in that regard. I do keep things heavily separated and
>partitioned, and I try hard to keep temporary data on RAM disks instead of
>real filesystems. If I do need a large amount of temporary storage on a
>system, I'll give it its own dedicated filesystem instead of having it
>share a mount point with the root filesystem or similar; I've always found
>it to be good practice to keep partitions separated from each other by
>functional task. Not only does it mean that fragmentation isn't a problem
>across those filesystems, but it means that it's easy to work with backing
>up and restoring an individual filesystem based on its purpose (and since
>some filesystems change less frequently than others, it is somewhat easier
>to back up data efficiently).
>
>Anyway, that's really all I've the energy to spew forth tonight. Of
>course, if you're interested, there is _plenty_ out there to search about
>and read up on. I'd recommend starting with learning about relatively
>simple filesystems like the FAT family, and then research progressively
>more complex filesystems and what functionality they provide. Then start
>looking into various different implementations of those filesystems
>(usually, operating system kernels) to see how they combat (or ignore!)
>the problems of filesystem fragmentation and other filesystem agnostic issues.
>
>Filesystems can be a very fascinating thing to learn about...
--------------------------
(PS - If you email me and don't get a quick response, you might want to
call on the phone. I get about 300 emails per day from alternate energy
mailing lists and such. I don't always see new messages very quickly.)
Ron Frazier
770-205-9422 (O) Leave a message.
linuxdude AT c3energy.com
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mail.ale.org/pipermail/ale/attachments/20100913/27d88143/attachment.html
More information about the Ale
mailing list