Follow up to defrag validity discussion: please read
in [Storage]
|
Prev: Samsung HD753lj external drive- computer does'nt see
Next: Hands-on with the ioSafe Solo external hard drive
From: David Brown on 7 Jan 2010 07:39 Cronos wrote: > Rod Speed wrote: > >> Nope, its completely different. A lot of small files needs access to the >> directory information with ever file, a large fragmented file does not. >> > Yea, so? The read head of the HDD still has to move across the > platter(s) to read one file if it is fragmented is what he meant. God, > you fucks are anal. Did you not bother to read my other post pointing out the difference between multiple small files and a large fragmented file, or did you not understand it, or did you not agree with it? I'll try and help if I can - but only if I know you are trying to understand the issues involved.
From: Arno on 7 Jan 2010 10:17 Joep <available(a)request.nl> wrote: > "Arno" <me(a)privacy.net> schreef in bericht > news:7qj8ghFb2bU1(a)mid.individual.net... >> >> Not quite: With many smaller files there is at likely one additional >> disk access for the metadata when a new one is opened, > At some point > while with >> one large fragmented file, there should be less than one access per >> pragment for metadata, at least with a sane OS. >> >> The observable difference in access times may depend on the >> filesystem in question. >> >> Arno > Joep This response looks a bit incomplete... -- Arno Wagner, Dr. sc. techn., Dipl. Inform., CISSP -- Email: arno(a)wagner.name GnuPG: ID: 1E25338F FP: 0C30 5782 9D93 F785 E79C 0296 797F 6B50 1E25 338F ---- Cuddly UI's are the manifestation of wishful thinking. -- Dylan Evans
From: Arno on 7 Jan 2010 10:19 Cronos <cronos(a)sphere.invalid> wrote: > Ed Light wrote: >> >> But a very fragmented large file is like a bunch of little files spread >> all over the place, isn't it? > Yes. Not at all. Sorry. There is metadata and not all of it is typically kept in RAM. It also has to be flushed to disk occasionally. Arno -- Arno Wagner, Dr. sc. techn., Dipl. Inform., CISSP -- Email: arno(a)wagner.name GnuPG: ID: 1E25338F FP: 0C30 5782 9D93 F785 E79C 0296 797F 6B50 1E25 338F ---- Cuddly UI's are the manifestation of wishful thinking. -- Dylan Evans
From: Arno on 7 Jan 2010 10:26 David Brown <david(a)westcontrol.removethisbit.com> wrote: > Cronos wrote: >> David Brown wrote: >>> (Note that I am discrediting your arguments >>> here, not you personally.) >> >> You are not even doing that because you are now arguing with industry >> experts and not me. > I am not arguing with any "industry experts". I am merely pointing out > errors in quotations you have copied from some unknown source. > Even if the source of these comments is in fact someone with experience > and a job setting up or maintaining large databases, this does not > qualify him as an "industry expert". It does, but database file accesses are different. They try to keep everything in RAM and actually get down to a very small number of non-data accesses. Filesystem accesses are more like 1...2 extra seeks per file open in the best case. > And even if he /is/ an industry > expert, that does not mean he is right in every point connected to his > job. Even experts get things wrong. And for any given opinion, you can > easily find a dozen "experts" with different views. Indeed. See above. > In summary, to make a database server fail due to fragmentation you > would have to try exceedingly hard to overload and misconfigure the > system, even if you use a badly designed database server on a badly > designed operating system, and badly fragment the disk. Maybe it takes > an "industry expert" to be able to achieve this. Actually, if you want high performance databases, you take out the filesystem and let the database system handle the storage directly. That way you do not get any filesystem fragmentation, because there actually is no filesystem anymore in the strict sense. Anyways, examples from database systems are unsuitable to discuss filesystem fragmentation. And, yes, putting a large database on an ordinary filesystem can slow it down to a crawl. Arno -- Arno Wagner, Dr. sc. techn., Dipl. Inform., CISSP -- Email: arno(a)wagner.name GnuPG: ID: 1E25338F FP: 0C30 5782 9D93 F785 E79C 0296 797F 6B50 1E25 338F ---- Cuddly UI's are the manifestation of wishful thinking. -- Dylan Evans
From: Arno on 7 Jan 2010 10:34
David Brown <david(a)westcontrol.removethisbit.com> wrote: > Cronos wrote: >> Rod Speed wrote: >> >>> Nope, its completely different. A lot of small files needs access to the >>> directory information with ever file, a large fragmented file does not. >>> >> Yea, so? The read head of the HDD still has to move across the >> platter(s) to read one file if it is fragmented is what he meant. God, >> you fucks are anal. > Did you not bother to read my other post pointing out the difference > between multiple small files and a large fragmented file, or did you not > understand it, or did you not agree with it? I'll try and help if I can > - but only if I know you are trying to understand the issues involved. I think Cronos does not understand what filesystem metadata is and how/where it is stored. That would explain his cluelessness. His manners are atrocious, to say the least. Arno -- Arno Wagner, Dr. sc. techn., Dipl. Inform., CISSP -- Email: arno(a)wagner.name GnuPG: ID: 1E25338F FP: 0C30 5782 9D93 F785 E79C 0296 797F 6B50 1E25 338F ---- Cuddly UI's are the manifestation of wishful thinking. -- Dylan Evans |