Stack size was only a problem for the 32 bit OS and not 64 bit. If one is dealing with a terabyte or more of data, I don't see them using a 32 bit OS. I really don't see any really good reasons for using anything but 64 bit any more, if the hardware supports it.
Brent L. Bates wrote:
Stack size was only a problem for the 32 bit OS and not 64 bit. Ifone is dealing with a terabyte or more of data, I don't see them using a 32 bit OS. I really don't see any really good reasons for using anything
but 64
bit any more, if the hardware supports it.
I dunno what the problem is - I haven't looked up the bug - but I'm doing this on 64-bit servers, and the bug's there, as someone noted, if you have lots of hard links (think rsync backups).
mark
Stack size was only a problem for the 32 bit OS and not 64 bit. If oneis dealing with a terabyte or more of data, I don't see them using a 32 bit OS.
Huh;
/dev/mapper/Raid5-Media 3.3T 3.1T 216G 94% /Media
% uname -sr Linux 2.6.18-194.3.1.el5PAE
I really don't see any really good reasons for using anything but 64 bit any more, if the hardware supports it.
I don't find the RedHat 32bit/64bit split to be as clean as it should be (definitely messy when compared to Solaris). When it comes to needing to install 32bit and 64bit versions of the same program (eg perl 'cos you only have 32bit binary libraries from vendors) it gets a little hairy. And then Oracle really starts to get antsy on you.
As a result, when I first installed CentOS 5 I stuck with 32bit because it was more stable. After all, my memory footprint is only around 200Mb on this machine; the rest is cache!
On 8/31/2010 11:04 AM, Stephen Harris wrote:
Stack size was only a problem for the 32 bit OS and not 64 bit. If oneis dealing with a terabyte or more of data, I don't see them using a 32 bit OS.
Huh;
/dev/mapper/Raid5-Media 3.3T 3.1T 216G 94% /Media
% uname -sr Linux 2.6.18-194.3.1.el5PAE
I really don't see any really good reasons for using anything but 64 bit any more, if the hardware supports it.
I don't find the RedHat 32bit/64bit split to be as clean as it should be (definitely messy when compared to Solaris). When it comes to needing to install 32bit and 64bit versions of the same program (eg perl 'cos you only have 32bit binary libraries from vendors) it gets a little hairy. And then Oracle really starts to get antsy on you.
As a result, when I first installed CentOS 5 I stuck with 32bit because it was more stable. After all, my memory footprint is only around 200Mb on this machine; the rest is cache!
The kernel and user apps are pretty much different things. You can run a 64-bit kernel and 32-bit apps if you want. But the issue with a 32-bit kernel besides what it can provide as a process address space is that at least the way RH and CentOS build it, it uses 4k stacks which may not be enough for some xfs operations.
Les Mikesell wrote:
On 8/31/2010 11:04 AM, Stephen Harris wrote:
Stack size was only a problem for the 32 bit OS and not 64 bit. If oneis dealing with a terabyte or more of data, I don't see them using a 32 bit OS.
Huh;
/dev/mapper/Raid5-Media 3.3T 3.1T 216G 94% /Media
% uname -sr Linux 2.6.18-194.3.1.el5PAE
I really don't see any really good reasons for using anything but 64 bit any more, if the hardware supports it.
I don't find the RedHat 32bit/64bit split to be as clean as it should be (definitely messy when compared to Solaris). When it comes to needing to install 32bit and 64bit versions of the same program (eg perl 'cos you only have 32bit binary libraries from vendors) it gets a little hairy. And then Oracle really starts to get antsy on you.
As a result, when I first installed CentOS 5 I stuck with 32bit because it was more stable. After all, my memory footprint is only around 200Mb on this machine; the rest is cache!
The kernel and user apps are pretty much different things. You can run a 64-bit kernel and 32-bit apps if you want. But the issue with a 32-bit kernel besides what it can provide as a process address space is that at least the way RH and CentOS build it, it uses 4k stacks which may not be enough for some xfs operations.
Are you saying here that I can take a system that has been installed from a 32 bit distribution and simply replace the kernel with a 64 bit kernel?
Thanks, Nataraj
On 9/1/10 12:43 AM, Nataraj wrote:
Les Mikesell wrote:
On 8/31/2010 11:04 AM, Stephen Harris wrote:
Stack size was only a problem for the 32 bit OS and not 64 bit. If oneis dealing with a terabyte or more of data, I don't see them using a 32 bit OS.
Huh;
/dev/mapper/Raid5-Media 3.3T 3.1T 216G 94% /Media
% uname -sr Linux 2.6.18-194.3.1.el5PAE
I really don't see any really good reasons for using anything but 64 bit any more, if the hardware supports it.
I don't find the RedHat 32bit/64bit split to be as clean as it should be (definitely messy when compared to Solaris). When it comes to needing to install 32bit and 64bit versions of the same program (eg perl 'cos you only have 32bit binary libraries from vendors) it gets a little hairy. And then Oracle really starts to get antsy on you.
As a result, when I first installed CentOS 5 I stuck with 32bit because it was more stable. After all, my memory footprint is only around 200Mb on this machine; the rest is cache!
The kernel and user apps are pretty much different things. You can run a 64-bit kernel and 32-bit apps if you want. But the issue with a 32-bit kernel besides what it can provide as a process address space is that at least the way RH and CentOS build it, it uses 4k stacks which may not be enough for some xfs operations.
Are you saying here that I can take a system that has been installed from a 32 bit distribution and simply replace the kernel with a 64 bit kernel?
I'm not sure how much 64-bit support the kernel expects so there might be some complications going that direction, but you can certainly install a 64-bit system and run the 32-bit versions of the apps and have both versions of most libraries available.
I'm not sure how much 64-bit support the kernel expects so there might be some complications going that direction, but you can certainly install a 64-bit system and run the 32-bit versions of the apps and have both versions of most libraries available.
To bring some closure to this thread, I ended up using a 64 bit Ubuntu Desktop Live CD which comes with e2fsck version 1.41. Here are the steps required:
sudo /bin/su - root modprobe dm_mod apt-get install lvm2 vgscan vgchange -a y lvscan e2fsck /dev/path/to/partition
This worked and the fsck completed within a few hours.
-
Brent L. Bates -
Les Mikesell -
m.roth＠5-cent.us -
Nataraj -
Sean Carolan -
Stephen Harris