On Fri, 26 Dec 2008 23:02:38 +0200, Nikos Chantziaras wrote:
> Well, instead of "yesterday" let's just say "the past 5 months". I
> already did the rsync/format thing a few times over the last years, and
> the results are always the same: very fast filesystem for about a
> month, then it starts
Dale wrote:
But if we learned to much, we may be dangerous or something. Sometimes
to much knowledge can be bad. lol
I !think! I tried XFS once. If it was XFS, you need to have a UPS for
sure. Every time the system crashed I had to re-install. I never got
it to recover even once. I have he
Nikos Chantziaras wrote:
> Dale wrote:
>> Nikos Chantziaras wrote:
>>> I already did the rsync/format thing a few times over the last years,
>>> and the results are always the same: very fast filesystem for about a
>>> month, then it starts getting slower over time.
>>
>> I have to say that after m
Matt Harrison wrote:
> Dale wrote:
>> I have to say that after my recent transfer, my login got a whole one
>> second faster. I can't tell any difference anywhere else. Of course,
>> portage has always been on its own partition and used ext3.
>>
>> We need a hard drive engineer on here. :/
>>
>>
Dale wrote:
Nikos Chantziaras wrote:
I already did the rsync/format thing a few times over the last years,
and the results are always the same: very fast filesystem for about a
month, then it starts getting slower over time.
I have to say that after my recent transfer, my login got a whole one
Dale wrote:
I have to say that after my recent transfer, my login got a whole one
second faster. I can't tell any difference anywhere else. Of course,
portage has always been on its own partition and used ext3.
We need a hard drive engineer on here. :/
Dale
:-) :-)
Hey, I've been follo
Nikos Chantziaras wrote:
> Alan McKinnon wrote:
>> On Friday 26 December 2008 21:49:02 Nikos Chantziaras wrote:
>>
>>> OK, I once again verified that fragmentation seems to be a big issue
>>> even on Linux. I just migrated to ext4, and in order to do that I had
>>> to rsync, format and rsync back.
Nikos Chantziaras wrote:
> Dale wrote:
>> Nikos Chantziaras wrote:
>>> OK, I once again verified that fragmentation seems to be a big issue
>>> even on Linux. I just migrated to ext4, and in order to do that I had
>>> to rsync, format and rsync back. The result is similar to the last
>>> time I d
Alan McKinnon wrote:
On Friday 26 December 2008 21:49:02 Nikos Chantziaras wrote:
OK, I once again verified that fragmentation seems to be a big issue
even on Linux. I just migrated to ext4, and in order to do that I had
to rsync, format and rsync back. The result is similar to the last time
On Friday 26 December 2008 21:49:02 Nikos Chantziaras wrote:
> OK, I once again verified that fragmentation seems to be a big issue
> even on Linux. I just migrated to ext4, and in order to do that I had
> to rsync, format and rsync back. The result is similar to the last time
> I did this (over
Dale wrote:
Nikos Chantziaras wrote:
OK, I once again verified that fragmentation seems to be a big issue
even on Linux. I just migrated to ext4, and in order to do that I had
to rsync, format and rsync back. The result is similar to the last
time I did this (over 8 months ago):
emerge --sync
Nikos Chantziaras wrote:
> Nikos Chantziaras wrote:
>> Jorge Peixoto de Morais Neto wrote:
>> [...] what would be the best way to defrag it?
> By not defragging it.
> [...]
I don't buy into that argument and never did. Every few months I
copy the
whole HD to another one
Nikos Chantziaras wrote:
Jorge Peixoto de Morais Neto wrote:
[...] what would be the best way to defrag it?
By not defragging it.
[...]
I don't buy into that argument and never did. Every few months I
copy the
whole HD to another one and then back to counter fragmentation (ext3)
and
the sys
On Tuesday 16 December 2008, Miguel Ramos wrote:
> Another argument in favour of cp in Linux: holes in sparse files are
> kept correctly, whereas using tar they are not.
>
> It is curious that this is very OS dependent.
> In FreeBSD, with cp, holes always go away, using tar, or better
> dump/restor
Neil Bothwick wrote:
> On Wed, 17 Dec 2008 06:20:38 -0600, Dale wrote:
>
>
>> I got it transfered over. I noticed something weird tho. I was booted
>> from the CD. When I was checking the permissions to make sure things
>> were going well, it kept showing gentoo:users instead of dale:users fo
On Wed, 17 Dec 2008 06:20:38 -0600, Dale wrote:
> I got it transfered over. I noticed something weird tho. I was booted
> from the CD. When I was checking the permissions to make sure things
> were going well, it kept showing gentoo:users instead of dale:users for
> example. The ones that were
Neil Bothwick wrote:
> On Tue, 16 Dec 2008 19:06:06 -0600, Dale wrote:
>
>
>> Light bulb warning. So null and console are on the drive for it to
>> start up but once it mounts /dev then it uses that "virtual" thing?
>> Cool, if I understand that correctly.
>>
>
> Yes, those two devices a
On Tue, 16 Dec 2008 19:06:06 -0600, Dale wrote:
> Light bulb warning. So null and console are on the drive for it to
> start up but once it mounts /dev then it uses that "virtual" thing?
> Cool, if I understand that correctly.
Yes, those two devices are needed before udev starts,so they have t
Neil Bothwick wrote:
> On Tue, 16 Dec 2008 17:49:11 -0600, Dale wrote:
>
>
I made a note of that command and will give that a try. I'll also
read the man page to see how to get it to skip /dev /sys /proc etc
etc.
>
>
>>> That's what the -x is for.
>>>
>
>
On Tue, 16 Dec 2008 17:49:11 -0600, Dale wrote:
> >> I made a note of that command and will give that a try. I'll also
> >> read the man page to see how to get it to skip /dev /sys /proc etc
> >> etc.
> > That's what the -x is for.
> Thanks for the info. As you may can tell, I have never used
Neil Bothwick wrote:
> On Tue, 16 Dec 2008 15:34:28 -0600, Dale wrote:
>
>
>>> rsync -ax /source/ /dest/
>>>
>
>
>> I made a note of that command and will give that a try. I'll also read
>> the man page to see how to get it to skip /dev /sys /proc etc etc.
>>
>
> That's what the
On Tue, 16 Dec 2008 15:34:28 -0600, Dale wrote:
> > rsync -ax /source/ /dest/
> I made a note of that command and will give that a try. I'll also read
> the man page to see how to get it to skip /dev /sys /proc etc etc.
That's what the -x is for.
--
Neil Bothwick
Be nice to moderators. The
Neil Bothwick wrote:
> On Tue, 16 Dec 2008 10:32:00 +0100, Daniel Troeder wrote:
>
>
>> While this will work perfectly well, this command is a waste of
>> resources. The compression ("-z") makes locally no sense, and there is
>> no need to tar the data (which will basically just concat files). Y
On Tue, 16 Dec 2008 10:32:00 +0100, Daniel Troeder wrote:
> While this will work perfectly well, this command is a waste of
> resources. The compression ("-z") makes locally no sense, and there is
> no need to tar the data (which will basically just concat files). You
> will get the exact same res
Another argument in favour of cp in Linux: holes in sparse files are
kept correctly, whereas using tar they are not.
It is curious that this is very OS dependent.
In FreeBSD, with cp, holes always go away, using tar, or better
dump/restore is a way to keep all file attributes.
In Linux, cp -a seem
Daniel Troeder wrote:
> Am Dienstag, den 16.12.2008, 03:15 -0600 schrieb Dale:
>
>> Daniel Troeder wrote:
>>
>>> Am Dienstag, den 16.12.2008, 01:59 -0600 schrieb Dale:
>>>
>>>
I'm not to worried about this since I will be moving this over to the
other drive anyway. I wo
Am Dienstag, den 16.12.2008, 03:15 -0600 schrieb Dale:
> Daniel Troeder wrote:
> > Am Dienstag, den 16.12.2008, 01:59 -0600 schrieb Dale:
> >
> >>
> >> I'm not to worried about this since I will be moving this over to the
> >> other drive anyway. I would like to know what command I should use t
Daniel Troeder wrote:
> Am Dienstag, den 16.12.2008, 01:59 -0600 schrieb Dale:
>
>>
>> I'm not to worried about this since I will be moving this over to the
>> other drive anyway. I would like to know what command I should use to
>> tar up everything, transfer it over and untar it all on one li
Am Dienstag, den 16.12.2008, 01:59 -0600 schrieb Dale:
> Dale wrote:
> > Dale wrote:
> >
> >> This is interesting. I am starting a new install on my backup drive.
> >> I'm part way through the install, fetching all the KDE stuff right now.
> >> This is what I got from the little frag script:
Dale wrote:
> Dale wrote:
>
>> This is interesting. I am starting a new install on my backup drive.
>> I'm part way through the install, fetching all the KDE stuff right now.
>> This is what I got from the little frag script:
>>
>> r...@smoker / # /root/fragck.pl /backup/
>> 0.953336175120985
Dale wrote:
>
> This is interesting. I am starting a new install on my backup drive.
> I'm part way through the install, fetching all the KDE stuff right now.
> This is what I got from the little frag script:
>
> [EMAIL PROTECTED] / # /root/fragck.pl /backup/
> 0.953336175120985% non contiguous
Alan McKinnon wrote:
>
> Only a proper analysis of your files will tell you this. It's easy enough to
> check for individual file fragmentation and get stats on that before you do
> the copy-off/copy-back.
>
>
>
>
This is interesting. I am starting a new install on my backup drive.
I'm part
On Friday 28 November 2008 20:24:38 Nikos Chantziaras wrote:
> Alan McKinnon wrote:
> > On Friday 28 November 2008 13:14:42 Dale wrote:
> >> If this is a little high, what would be the best way to defrag it?
> >
> > By not defragging it.
> >
> > It's not Windows. Windows boxes needs defragging not
Jorge Peixoto de Morais Neto wrote:
[...] what would be the best way to defrag it?
>>> By not defragging it.
>>>
>>> It's not Windows. Windows boxes needs defragging not because fragmentation
>>> is a huge problem in itself, but because windows filesystems are a steaming
>>> mess
On 28 Nov 2008, at 19:27, Jorge Peixoto de Morais Neto wrote:
...
I don't buy into that argument and never did. Every few months I
copy the
whole HD to another one and then back to counter fragmentation
(ext3) and
the system becomes noticeably faster after doing it (speed increase
in
emer
Jorge Peixoto de Morais Neto wrote:
[...] what would be the best way to defrag it?
By not defragging it.
It's not Windows. Windows boxes needs defragging not because fragmentation
is a huge problem in itself, but because windows filesystems are a steaming
mess of [EMAIL PROTECTED] that do littl
>>> [...] what would be the best way to defrag it?
>>
>> By not defragging it.
>>
>> It's not Windows. Windows boxes needs defragging not because fragmentation
>> is a huge problem in itself, but because windows filesystems are a steaming
>> mess of [EMAIL PROTECTED] that do little right and most t
Alan McKinnon wrote:
On Friday 28 November 2008 13:14:42 Dale wrote:
If this is a little high, what would be the best way to defrag it?
By not defragging it.
It's not Windows. Windows boxes needs defragging not because fragmentation is
a huge problem in itself, but because windows filesystem
38 matches
Mail list logo
