... 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
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 :)
___
CP/M was single-user and was used on floppies up to 360kB AFAIK,
And MP/M was multi-user, using the same filesystem. From memory, there
was perhaps one byte that indicated which user owned a file :)
in CP/M there were users too, but it was just to help keeping it clear,
not for security,
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.
At 15:21 28/08/2008, RW wrote:
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
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 using a
On Fri, 29 Aug 2008 13:44:20 +1000 (EST)
Ian Smith [EMAIL PROTECTED] wrote:
On Thu, 28 Aug 2008 13:33:35 +0200 (CEST)
Wojciech Puchar [EMAIL PROTECTED] wrote:
CP/M was single-user and was used on floppies up to 360kB AFAIK,
And MP/M was multi-user, using the same filesystem. From
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 periodic
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 needs periodic
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, unlike scandisk
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.
CP/M was
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
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
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
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
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.
usersgroups 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
because in unix they are not actually needed.
usersgroups 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
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 figures
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
intentionally fragmented in a controlled way
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
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
On Thu, 28 Aug 2008 13:33:35 +0200 (CEST)
Wojciech Puchar [EMAIL PROTECTED] wrote:
CP/M was single-user and was used on floppies up to 360kB AFAIK,
And MP/M was multi-user, using the same filesystem. From memory, there
was perhaps one byte that indicated which user owned a file :)
NTFS
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, but I don't
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', how does *nix deal
with it?
The short
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 *nix get away
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 puzzled me for years (but i've never got
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
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
system,
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:
[~]gunzip
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
On Thu, 1 Mar 2007 13:50:44 -0700 Steve Franks wrote:
Excellent! Never had that one answered. I've gone down the typical
road of being an MS booster (It doesn't take 10 hours to set up and
configure) to experiencing glee when I find yet another way FBSD
kicks the crap out of MS. Why?
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 only
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
___
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 10
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 lessen
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
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)
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-emphasized
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
___
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_disk is enough
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 -c
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 explantion if so?
Thanks,
Steve
I'm thinking this one's
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 pristine
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:
[~]gunzip -c
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 an issue.
jerry
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
--
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's in the FAQ at
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
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 could gain few
Excellent! Never had that one answered. I've gone down the typical
road of being an MS booster (It doesn't take 10 hours to set up and
configure) to experiencing glee when I find yet another way FBSD
kicks the crap out of MS. Why? Because I've grown up, and learned
that 2 hours time spent
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
issue on UFS? Can someone point me to an explantion if so?
Steve Franks wrote:
Excellent! Never had that one answered. I've gone down the typical
road of being an MS booster (It doesn't take 10 hours to set up and
configure) to experiencing glee when I find yet another way FBSD
kicks the crap out of MS. Why? Because I've grown up, and learned
that 2
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:
fsck /usr
**
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?
I've been told that most modern
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 explantion if so?
fsck will tell you the level of
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 drive offline).
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? Can someone point me to an explantion if so?
I've been
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 n5 years.
Robert Huff
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 are not
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
backup)
and restore - or simply
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 _not_ the same as
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)
and restore - or simply restore on top (if you backed
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 as fragmentation
on 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 will be defrag
you mean : backup, format,
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 on other
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
space.
On Mar 1, 2007, at 2:56 PM, Ivan Voras wrote:
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
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 became mainstream.
Meaning that NTFS is cured of this ??
I
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, but
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 to
71 matches
Mail list logo
