How come I never hear defrag come up as a topic, and can't find
anything related to defrag in the ports tree? Is it really not an
issue on UFS? Can someone point me to an explantion if so?
Thanks,
Steve
___
freebsd-questions@freebsd.org mailing
something that has puzzled me for years (but i've never got around to
asking) is how does *nix get away without regular defrag as with
windoze.
fsck is equivalent to scandisk, right?
so when you delete files and start getting 'holes', how does *nix deal
with it?
--
In f
On Thu, Mar 01, 2007 at 09:49:09AM -0700, Steve Franks wrote:
> How come I never hear defrag come up as a topic, and can't find
> anything related to defrag in the ports tree? Is it really not an
> issue on UFS? Can someone point me to an explantion if so?
It's really not a
Steve Franks wrote:
How come I never hear defrag come up as a topic, and can't find
anything related to defrag in the ports tree? Is it really not an
issue on UFS? Can someone point me to an explantion if so?
Thanks,
Steve
I'm thinking this one's in the FAQ at freebsd.org
Kevin Kinsey wrote:
Steve Franks wrote:
How come I never hear defrag come up as a topic, and can't find
anything related to defrag in the ports tree? Is it really not an
issue on UFS? Can someone point me to an explantion if so?
Thanks,
Steve
I'm thinking this one'
On 3/1/07, Kevin Kinsey <[EMAIL PROTECTED]> wrote:
Kevin Kinsey wrote:
groff /usr/share/doc/smm/05.fastfs/* > ~/ffs.ps
/\/\
--
Pietro Cerutti
- ASCII Ribbon Campaign -
against HTML e-mail and
proprietary attachments
www.asciiribbon
How come I never hear defrag come up as a topic, and can't find
anything related to defrag in the ports tree? Is it really not an
issue on UFS? Can someone point me to an explantion if so?
unless you'll keep your filesystem always near-full it's not an issue.
POSSIBLY it
a MS laptop that has degraded to the point where any disk
acess takes 10 seconds before the display updates (but not from the
shell - so not a defrag issue, just a screwed registry or something).
I used to reinstall my entire MS server every 6 months, on average...
Steve
On 3/1/07, Kevin Kinsey <
On Thu, Mar 01, 2007 at 11:21:16AM -0600, Kevin Kinsey wrote:
> Kevin Kinsey wrote:
> >Steve Franks wrote:
> >>How come I never hear defrag come up as a topic, and can't find
> >>anything related to defrag in the ports tree? Is it really not an
> >>
I write
this, I'm on a MS laptop that has degraded to the point where any disk
acess takes 10 seconds before the display updates (but not from the
shell - so not a defrag issue, just a screwed registry or something).
I used to reinstall my entire MS server every 6 months, on average...
Steve
The
Steve Franks wrote:
> How come I never hear defrag come up as a topic, and can't find
> anything related to defrag in the ports tree? Is it really not an
> issue on UFS? Can someone point me to an explantion if so?
fsck will tell you the level of fragmentation on the file system
On Thu, March 1, 2007 3:35 pm, Ivan Voras wrote:
> Steve Franks wrote:
>> How come I never hear defrag come up as a topic, and can't find
>> anything related to defrag in the ports tree? Is it really not an
>> issue on UFS? Can someone point me to an explantion if so?
In response to Ivan Voras <[EMAIL PROTECTED]>:
> Steve Franks wrote:
> > How come I never hear defrag come up as a topic, and can't find
> > anything related to defrag in the ports tree? Is it really not an
> > issue on UFS? Can someone point me to an explantio
On Thu, 1 Mar 2007 19:22:32 +0100 (CET)
Wojciech Puchar <[EMAIL PROTECTED]> wrote:
> backup+restore will be defrag
you mean : backup, format, (reinstall if needed, depending on method of backup)
and restore - or simply restore on top (if you backed up everything and can
access your driv
Richard Lynch wrote:
> On Thu, March 1, 2007 3:35 pm, Ivan Voras wrote:
>> Steve Franks wrote:
>>> How come I never hear defrag come up as a topic, and can't find
>>> anything related to defrag in the ports tree? Is it really not an
>>> issue on UFS? Ca
Richard Lynch writes:
> So that the need to do "defrag" is essentially almost 0 for
> almost all users.
For one of my boxes, with three filesystems, the "frag %" has
been (0,8, 0.4, 1.1).
For n>5 years.
Bill Moran wrote:
> In response to Ivan Voras <[EMAIL PROTECTED]>:
>> 352462 files, 2525857 used, 875044 free (115156 frags, 94986 blocks,
>> 3.4% fragmentation)
>
> Just to reiterate:
> "Fragmentation" on a Windows filesystem is _not_ the same as "fragmentation"
> on a unix file system. They a
On Fri, Mar 02, 2007 at 08:51:00AM +1100, Norberto Meijome wrote:
> On Thu, 1 Mar 2007 19:22:32 +0100 (CET)
> Wojciech Puchar <[EMAIL PROTECTED]> wrote:
>
> > backup+restore will be defrag
>
> you mean : backup, format, (reinstall if needed, depending on method of
&
In response to Ivan Voras <[EMAIL PROTECTED]>:
> Bill Moran wrote:
> > In response to Ivan Voras <[EMAIL PROTECTED]>:
>
> >> 352462 files, 2525857 used, 875044 free (115156 frags, 94986 blocks,
> >> 3.4% fragmentation)
>
> >
> > Just to reiterate:
> > "Fragmentation" on a Windows filesystem is
Norberto Meijome <[EMAIL PROTECTED]> writes:
> On Thu, 1 Mar 2007 19:22:32 +0100 (CET)
> Wojciech Puchar <[EMAIL PROTECTED]> wrote:
>
>> backup+restore will be defrag
>
> you mean : backup, format, (reinstall if needed, depending on method of
> backup)
>
Ivan Voras <[EMAIL PROTECTED]> writes:
> Bill Moran wrote:
>> In response to Ivan Voras <[EMAIL PROTECTED]>:
>
>>> 352462 files, 2525857 used, 875044 free (115156 frags, 94986 blocks,
>>> 3.4% fragmentation)
>
>>
>> Just to reiterate:
>> "Fragmentation" on a Windows filesystem is _not_ the same a
On Thu, Mar 01, 2007 at 05:17:38PM -0500, Jerry McAllister wrote:
> On Fri, Mar 02, 2007 at 08:51:00AM +1100, Norberto Meijome wrote:
>
> > On Thu, 1 Mar 2007 19:22:32 +0100 (CET)
> > Wojciech Puchar <[EMAIL PROTECTED]> wrote:
> >
> > > backup+restore wi
Bill Moran wrote:
> In response to Ivan Voras <[EMAIL PROTECTED]>:
>> I believe that a "fragmented file" in common usage refers to a file
>> which is not stored continuously on the drive - i.e. it occupies more
>> than one continuous region. How is UFS fragmentation different than
>> fragmentation
Lowell Gilbert wrote:
> If you know the standard computer science terminology, it can be
> described quite tersely. UFS fragmentation is a way of avoiding
> internal fragmentation from wasting too much space. MS-DOS-FS
> fragmentation is an example of external fragmentation in the storage
> spac
discussion has been about UFS vs MS file system. But I have been
using Macs and have run file system utilities, Norton, and watched it
defrag
a Mac disc. I am just curious as to how the HFS and HFS+ file systems
fit
into this picture. Particularly since OSX is essentially a Unix 'like'
On Thu, 01 Mar 2007 22:56:02 +0100
Ivan Voras <[EMAIL PROTECTED]> wrote:
> > So that the need to do "defrag" is essentially almost 0 for almost all
> > users.
>
> For what it's worth, this has been Microsoft's official position since
> NTFS be
jekillen wrote:
> a Mac disc. I am just curious as to how the HFS and HFS+ file systems fit
> into this picture. Particularly since OSX is essentially a Unix 'like'
> system
> but still uses HFS+
> Just for some perspective and idle curiosity.
As you said, HFS(+) is not a native unix file system,
Jerry McAllister wrote:
> Well, it would do some, but for the greatest effect, you would need:
> dump + rm -rf * + restore
This is nitpicking so ignore it: deleting all files on UFS2 volume won't
restore it to it's pristine state because inodes are lazily initialized.
It doesn't have anything t
shell - so not a defrag issue, just a screwed registry or something).
I used to reinstall my entire MS server every 6 months, on average...
as rarely? looks that you are very good windows admin, or this MS server
wasn't used much
___
fr
Wojciech Puchar <[EMAIL PROTECTED]> wrote:
backup+restore will be defrag
you mean : backup, format, (reinstall if needed, depending on method of backup)
s/format/newfs/g
no reinstall, that's not windows.
after restoring all files, bsdlabel -B /dev/your_dis
On Thursday 01 March 2007 17:27, Pietro Cerutti wrote:
> On 3/1/07, Kevin Kinsey <[EMAIL PROTECTED]> wrote:
> > Kevin Kinsey wrote:
> >
> > groff /usr/share/doc/smm/05.fastfs/* > ~/ffs.ps
>
> /\/\
This is what worked for me:
[~]>gunzip
Kevin Kinsey wrote:
> Kevin Kinsey wrote:
>> Steve Franks wrote:
>>> How come I never hear defrag come up as a topic, and can't find
>>> anything related to defrag in the ports tree? Is it really not an
>>> issue on UFS? Can someone point me to an ex
On Fri, Mar 02, 2007 at 02:17:31AM +0100, Ivan Voras wrote:
> Jerry McAllister wrote:
>
> > Well, it would do some, but for the greatest effect, you would need:
> > dump + rm -rf * + restore
>
> This is nitpicking so ignore it: deleting all files on UFS2 volume won't
> restore it to it's prist
On 2007-03-02 11:27, Mario Lobo <[EMAIL PROTECTED]> wrote:
> On Thursday 01 March 2007 17:27, Pietro Cerutti wrote:
> > On 3/1/07, Kevin Kinsey <[EMAIL PROTECTED]> wrote:
> > > Kevin Kinsey wrote:
> > >
> > > groff /usr/share/doc/smm/05.fastfs/* > ~/ffs.ps
>
> This is what worked for me:
>
> [~]>
.
> Probably by a factor of 10 for me over the last 10 years. As I write
> this, I'm on a MS laptop that has degraded to the point where any disk
> acess takes 10 seconds before the display updates (but not from the
> shell - so not a defrag issue, just a screwed registry or somet
On Thu, 1 Mar 2007 17:39:05 -0500 Jerry McAllister wrote:
>> Well, it would do some, but for the greatest effect, you would need:
>> dump + rm -rf * + restore
>> That would get it all.
> Of course, I should have re-emphasized that this is not needed.
> You will not improve performance. Its on
On Fri, 2 Mar 2007 11:12:25 -0500 Jerry McAllister wrote:
> On the other hand, doing all this either way wouldn't make any difference
> in performance for file access in a running system because so-called
> fragmentation is not an issue in the UNIX file system - except in
> the small possibility
On Thu, 01 Mar 2007 22:56:02 +0100 Ivan Voras wrote:
> For what it's worth, this has been Microsoft's official position since
> NTFS became mainstream.
As usual, it's not worth much if it come from Microsoft...
Regards
Chris
___
freebsd-questions@freeb
On Thu, 1 Mar 2007 17:21:57 -0500 Bill Moran wrote:
> But this also makes it _easy_ for the filesystem to avoid causing the type
> of fragmentation that _does_ degrade performance. For example, when the
> first block is on track 10, then the next block is on track 20, then we're
> back to track 1
On Thu, 01 Mar 2007 23:56:30 +0100 Ivan Voras wrote:
> "UFS fragmentation" refers to dividing blocks (e.g. 16KB in size) into
> block fragments (e.g. 2KB in size) that can be allocated separately in
> special circumstances (which all boil down to: at the end of files).
> This is done to less
On Fri, 02 Mar 2007 02:14:07 +0100 Ivan Voras wrote:
> As you said, HFS(+) is not a native unix file system, but maybe someone
> will know about it. All I know about is that HFS+ is a journaling file
> system and that it defragments (in the Windows sense) files smaller than
> certain size (20MB?)
On Sat, 3 Mar 2007, Christian Baer wrote:
On Fri, 02 Mar 2007 02:14:07 +0100 Ivan Voras wrote:
As you said, HFS(+) is not a native unix file system, but maybe someone
will know about it. All I know about is that HFS+ is a journaling file
system and that it defragments (in the Windows sense) fi
On Sat, Mar 03, 2007 at 02:53:30PM +0100, Christian Baer wrote:
> On Thu, 1 Mar 2007 17:39:05 -0500 Jerry McAllister wrote:
>
> >> Well, it would do some, but for the greatest effect, you would need:
> >> dump + rm -rf * + restore
> >> That would get it all.
>
> > Of course, I should have re-e
As you said, HFS(+) is not a native unix file system, but maybe someone
will know about it. All I know about is that HFS+ is a journaling file
system and that it defragments (in the Windows sense) files smaller than
certain size (20MB?) on the fly.
This may be completely OT here, but I gotta ask
Giorgos Keramidas wrote:
On 2007-03-02 11:27, Mario Lobo <[EMAIL PROTECTED]> wrote:
On Thursday 01 March 2007 17:27, Pietro Cerutti wrote:
On 3/1/07, Kevin Kinsey <[EMAIL PROTECTED]> wrote:
Kevin Kinsey wrote:
groff /usr/share/doc/smm/05.fastfs/* > ~/ffs.ps
This is what worked for me:
[~]>g
On Sat, 3 Mar 2007 15:01:12 +0100 (CET)
Christian Baer <[EMAIL PROTECTED]> wrote:
> You do know that you can use 'tunefs -m 0'? This will in fact cause
> fragmentation to happen - even on UFS2! UFS2 has methods of avoiding
> fragmentation that work quite well but it is not a 'magical' file
> syst
prad wrote:
> something that has puzzled me for years (but i've never got around to
> asking) is how does *nix get away without regular defrag as with
> windoze.
>
> fsck is equivalent to scandisk, right?
>
> so when you delete files and start getting 'holes
Maybe it is because FAT filesystem wasn't well designed from the
beginning and defrag was a workaround to solve performances problems.
-fred-
On Aug 27, 2008, at 5:29 PM, prad wrote:
something that has puzzled me for years (but i've never got around to
asking) is how does *ni
On August 27, 2008 09:35:42 pm Fred C wrote:
> Maybe it is because FAT filesystem wasn't well designed from the
> beginning and defrag was a workaround to solve performances problems.
>
> -fred-
>
> On Aug 27, 2008, at 5:29 PM, prad wrote:
> > something that has p
On Wed, 27 Aug 2008 22:08:47 -0400
Mike Jeays <[EMAIL PROTECTED]> wrote:
> That's true about FAT. What I have never understood is why Microsoft
> didn't fix the problem when they designed NTFS. UFS and EXT2 both
> existed at that time, and neither needs periodic defragmentation.
I think they
At 06:56 28/08/2008, you wrote:
On Wed, 27 Aug 2008 22:08:47 -0400
Mike Jeays <[EMAIL PROTECTED]> wrote:
> That's true about FAT. What I have never understood is why Microsoft
> didn't fix the problem when they designed NTFS. UFS and EXT2 both
> existed at that time, and neither needs periodi
RW <[EMAIL PROTECTED]> wrote:
>
> On Wed, 27 Aug 2008 22:08:47 -0400
> Mike Jeays <[EMAIL PROTECTED]> wrote:
>
> > That's true about FAT. What I have never understood is why Microsoft
> > didn't fix the problem when they designed NTFS. UFS and EXT2 both
> > existed at that time, and neither need
something that has puzzled me for years (but i've never got around to
asking) is how does *nix get away without regular defrag as with
windoze.
because it doesn't need it.
fsck is equivalent to scandisk, right?
not exactly - fsck usually fix errors, unlik
Maybe it is because FAT filesystem wasn't well designed from the beginning
and defrag was a workaround to solve performances problems.
as everything else microsoft did it wasn't designed but stoled, possibly
slightly changed.
FAT is similar (mostly the same) as CP/M filesystem.
That's true about FAT. What I have never understood is why Microsoft didn't
fix the problem when they designed NTFS. UFS and EXT2 both existed at that
time, and neither needs periodic defragmentation.
because Microsoft never fixes the real problems, but create it.
if they would fix most of th
I think they probably did, NTFS took a lot from UNIX filesystems, and
what for example?
it took 95% from OS/2 HPFS filesystem and another 5% is what microsoft
f...ed up.
at the time it was released they said that NTFS didn't
No, if you check a NTFS disk after some work, it's heavily fragmented. As you
fill it and work with it, it becomes more and more fragmented.
it's just like FAT, because nothing is done to prevent fragmentation.
if NTFS needs to allocate block, it simply get first free.
consider writing to 3 fi
MS was focused on building a filesytem that could store the outrageous
ACLs they wanted, and that was non-trival
so - as usually - they quickly implemented OS/2 filesystem (at best,
assuming no stolen code), and added their bloat then.
performance is never a priority in Microsoft. exactly opp
Wojciech Puchar wrote:
(look at how long it took the
BSDs to have native file-level ACLs).
because in unix they are not actually needed.
users&groups system is just perfect.
That's one man's opinion.
i don't know anyone here that actually use ACL under unix
because he/she needs it.
It de
because in unix they are not actually needed.
users&groups system is just perfect.
That's one man's opinion.
for sure not one. all local unix users (not linux fans) i know share the
same opinion
___
freebsd-questions@freebsd.org mailing list
http:
> On Thu, 28 Aug 2008 10:13:40 +0200
> Eduardo Morras <[EMAIL PROTECTED]> wrote:
>
> > No, if you check a NTFS disk after some work, it's heavily
> > fragmented. As you fill it and work with it, it becomes more and
> > more fragmented.
How did you measure it? AFAIK the percentage fragmentation f
On 8/27/08, prad <[EMAIL PROTECTED]> wrote:
> something that has puzzled me for years (but i've never got around to
> asking) is how does *nix get away without regular defrag as with
> windoze.
>
Essentially, the UFS file system (and its close relatives) is
intent
Essentially, the UFS file system (and its close relatives) is
intentionally fragmented in a controlled way as the files are written,
exactly that was invented over 20 years ago and still it works perfect.
at sort-of-random locations all over the disk, rather than starting at
it's definitely
you will get block arranged like this (where 1 is file 1's data,2 is
data from file 2 and 3 from file 3):
123123123123123123123123213213
This is just untrue. I don't much like Microsoft, but I don't think
i AM sure it is like that under DOS up to 6.2 (where i tested it), and
almost sure with
tinue to buy
> new versions of windoze and new hardware, just to do as simple task as
> writing a few-paged document or view a webpage
Yeah, yeah :) I'd be surprised if NTFS isn't as defrag-proof as HPFS,
which as I recall had self-defragging garbage-collecting features built
in
On Fri, 29 Aug 2008 02:43:40 +0200 (CEST)
Wojciech Puchar <[EMAIL PROTECTED]> wrote:
> >> you will get block arranged like this (where 1 is file 1's data,2
> >> is data from file 2 and 3 from file 3):
> >>
> >> 123123123123123123123123213213
> >
> > This is just untrue. I don't much like Microsoft
ged document or view a webpage
Yeah, yeah :) I'd be surprised if NTFS isn't as defrag-proof as HPFS,
which as I recall had self-defragging garbage-collecting features built
exactly like in microsoft. they quickly created similar filesystem not
even really understanding it, or if they did
at FAT.
possibly untrue in Win NT,
From what I've read, it's a journalling filesytem based on a
i mean FAT partition under NT.
I see that ext4 the successor to ext3, and which also has extent
support, has a defragmenter. And it appears to give significant
increases in read speeds.
still
re fragmented.
How did you measure it? AFAIK the percentage fragmentation figures given
by windows tools and fsck, aren't measured on the same basis.
I run jkdefrag. I outs an image of fragmented files. In practice
work, when i defrag the data disks i get 30-40 (even 50) MB/s when
copying f
How did you measure it? AFAIK the percentage fragmentation figures given
by windows tools and fsck, aren't measured on the same basis.
I run jkdefrag. I outs an image of fragmented files. In practice work, when i
defrag the data disks i get 30-40 (even 50) MB/s when copying files us
f all , I would be careful who I called an idiot. Secondly, you
obviously have no business knowledge. Products, whether they are cars,
drugs, etc. are improved and reissued to the general public. That is
just the name of the game.
>
> Yeah, yeah :) I'd be surprised if NTFS isn't a
... In logical sense yes, in physical sense no. They are video big files
(from 9 to 40 GB) that i edit, cut, apply video filters, recompress and stuff
so no. but still it's funny windoze can't keep fragmentation on files that
are processed in large chunks on system with lots of RAM.
even stup
First of all , I would be careful who I called an idiot. Secondly, you
obviously have no business knowledge.
i think i do have. and exactly described how it works.
of course if i would be microsoft's marketing guy, i won't use the word
idiot :)
___
73 matches
Mail list logo