FS types supporting large files


    Sponsored Links


  • 1. Replacing Disksuite mirrored disk in a D2
    D2 array attached to a 280R running S8 and disksuite 4.2.1. Got a bad disk which forms one side of a mirror (e.g. d10 is a mirror made up of d11 and d12, where d11 and d12 are entire physical disks, and d12 is kaput). The various docs are a bit sketchy ... should I be able to swap the disk while the system is live, fmthard it, and then just metasync it? Should I eliminate the existing metadevice (d12) before swapping the drive? I'm sure I did this before, though not with a D2, and I just swapped the disk and ran metasync, but I'm not 100% certain. Thanks, Mark
  • 2. Solaris 10, su - and PATH
    Can someone help verify something for me? In the past I could (assuming sudoers allows me to do this)... sudo /usr/bin/ksh (now I have a root shell) and then... su - someuser and my PATH would be set to the PATH of someuser, but in Solaris 10 it's like SUPATH is getting pulled in.. I'm left with just PATH=/usr/bin: instead of the user's login PATH. According to the man page (duh.. just stating this for those who don't know how su is supposed to behave), you get the environment of the user when you do an su - If I did just an su, then I'd expect the SUPATH behavior. This looks like a bug to me... but can somebody else try it out... I can't say I have latest patches (I will look into planning that).. so if someone can see if it behaves correctly, it may be that I simply need to schedule an update. Right now it's causing an installation script to fail.... and the behavior is NOT (IMHO) what it's supposed to be (especially since this problem hasn't shown up before).
  • 3. how thread-safe is getaddrinfo() ?
    I'm working with Solaris 10. How thread-safe is the getaddrinfo() function? The man page says it's "MT-Safe with exceptions". attributes(5) says that means: See the NOTES or USAGE sections of these pages for a description of the exceptions. but there is neither a NOTES or a USAGE section, nor any discussion of threads, in getaddrinfo(3SOCKET). Glenn
  • 4. NAS shares not mounting at boot (SUN to EMC Datamover)
    Hello, Have an issu where when a server is booted the NAS shares show up nine out of ten times. /nas/test lets say. Have run a snoop and made sure /etc/nsswitch has files dns in that order. Also put in the hostname and IP of datamover. Does anyone have any idea on why this is happening? Almost seems like a timing issue with DNS. Please let me know. John

FS types supporting large files

Postby Alona » Thu, 20 Mar 2008 01:49:19 GMT

Are large files supported by all types of file systems?
Is there a file system type where 64-bit file API functions xxx64()
would fail?

Thank you,

Re: FS types supporting large files

Postby andrew » Thu, 20 Mar 2008 17:31:00 GMT

In article < XXXX@XXXXX.COM >,
	Alona < XXXX@XXXXX.COM > writes:

FAT (DOS/Windows) filesystems don't support large files, but
the xxx64() functions will still work OK for files up to the
filesystem limit (4Gb, IIRC). Most of the standard unix commands
supplied with Solaris are built largefile aware, and if there
was a filesystem where the xxx64() functions didn't work, most
of the Solaris commands wouldn't work on it.

Note as stated before, you shouldn't be using the xxx64()
functions directly in your source code. You just supply the
appropriate command line options to the compile -- see

Andrew Gabriel
[email address is not usable -- followup in the newsgroup]

Re: FS types supporting large files

Postby Casper H.S. Dik » Thu, 20 Mar 2008 18:06:24 GMT

Alona < XXXX@XXXXX.COM > writes:

The xxx64() APIs (which you should not be using directly) do not
require that the underlying filesystem supports large files.

Internally, there is only one set of system calls and interfaces:
interfaces using 64 bit file offset pointers.  All filesystems
accept these.  Each filesystem has its own private limit when
it comes to actual supported filesizes.

Expressed in this posting are my opinions.  They are in no way related
to opinions held by my employer, Sun Microsystems.
Statements on Sun products included here are not gospel and may
be fiction rather than truth.

Similar Threads:

1.large file support && ! large file support

It seems a program cannot access BOTH the old (without large file support)
and new (with large file support) interfaces at the same time.  For example,
when large file support is not turned on, type off_t is 32 bits and off64_t
is not defined.  But when LFS is turned on, off64_t does get defined, and
off_t is redefined as 64 bits.

Is there a way to have both definitions active in their respective ways?

The purpose is building a library which provides certain kinds of wrapping
around system or library calls that do deal with interface changes due to
large file support.

| Phil Howard KA9WGN (ka9wgn.ham.org)  /  Do not send to the address below |
| first name lower case at ipal.net   /   XXXX@XXXXX.COM  |

2.Made e2fs filesystem, mount still says "fs type ntfs not supported by kernel"

Here's a goofy one...

I have two drives that used to be in Win2K machines and had NTFS
filesystems on them.

Installed both drives in a Red Hat 7.3 machine with 2.4.18-3 kernel
and no NTFS support.  Used fsck to delete the NTFS partitions and add
LInux partitions, then used mke2fs to make second extended filesystems
on the drives.  Then used e2fsck -f to check and make sure all is OK.

Then, I tried mounting the drives, and got  "fs type ntfs not
supported by kernel".

Obviously Windows did something to screw up my drive for other OSs
(big surprise!).  Any ideas on how to get around it?

Return to unix


Who is online

Users browsing this forum: No registered users and 49 guest