file size limits

It is going to be controlled by the application and then by actual disk space.

If you are just doing a machine to machine file copy, it will depend on the disk size.

The only time the filesystem (fat16,32) will come into play, is with the #of files. Beause FAT basically uses a table to point to each file. The table itself has a cap/limit on how many entries it can hold.

NTFS does not have this limitation.

But the application iteslf may have constraints.
Also if you are doing a over the net type of transfer, there may be bandwidth restrictions as well. Like if your proxy server limits how much data can be transferred per user.

"BTW- self-taught is the best way to learn computing. I have always stood by the mantra
"If you can't teach yourself, get out of IT"."

It might just be me, but it seems the self taught are becoming the last to leave and suffer through the current job market while the paper stamped ones are looking for the new green pasture.

In fact this is one of the reasons to use NTFS, besides security.

Chunk Size only has to do with how the OS can retrieve data from the disk subsystem.

A lower chuck size (32k for instance) wastes less space then a 64k chunk size. But it also means that you have to make more reads to the disk for information.

And vice versa; 64k means less reads, but if you write a 33k file, you just wasted 2 chunks.

The way this problem is avoided is at the controller layer. The more memory you have on the controller, the smaller the chunk size you can go without taking a performance hit.

You want it to be reliable and are sharing with other OS's, otherwise it can go to 4. FAT32 is definately 4gig file size (not partition size, although the 4 gig figure pops up there too). Try saving entire DVD's to a FAT32 and you'll see :)

The NTSF file size limit is up there in theory 2^64 is like 16 exabytes.... probably not a worry in the near future (but then in the XT days nobody thought you would EVER get into terrabytes either....)

Yes, that is correct. Sorry I didn't answer back sooner. HEre is all the info on file and volume size straight from the horses mouth, so to speak:

http://www.microsoft.com/technet/treeview/default.asp?url=/technet/prodtechnol/winxppro/reskit/prkc_fil_tdrn.asp

You will have to take out the spaces etc. to get the link to work as per usual on this board, but it will work and give you the lowdown on the MS restrictions.

~

Since URL's are kinda difficult here at TR.

Maximum Sizes on NTFS Volumes
In theory, the maximum NTFS volume size is 264 clusters minus 1 cluster. However, the maximum NTFS volume size as implemented in Windows XP Professional is 232 clusters minus 1 cluster. For example, using 64-KB clusters, the maximum NTFS volume size is 256 terabytes minus 64 KB. Using the default cluster size of 4 KB, the maximum NTFS volume size is 16 terabytes minus 4 KB.

Because partition tables on master boot record (MBR) disks only support partition sizes up to 2 terabytes, you must use dynamic volumes to create NTFS volumes over 2 terabytes. Windows XP Professional manages dynamic volumes in a special database instead of in the partition table, so dynamic volumes are not subject to the 2-terabyte physical limit imposed by the partition table. Therefore, dynamic NTFS volumes can be as large as the maximum volume size supported by NTFS. Itanium-based computers that use GUID partition table (GPT) disksalso support NTFS volumes larger than 2 terabytes.

Note

If you use large numbers of files in an NTFS folder (300,000 or more), disable short-file name generation, especially if the first six characters of the long file names are similar. For more information, see "Optimizing NTFS Performance" later in this chapter.
Table 13.5 lists NTFS size limits.

Table 13.5 NTFS Size Limits

Description Limit
Maximum file size Theory: 16 exabytes minus 1 KB (264 bytes minus 1 KB)
Implementation: 16 terabytes minus 64 KB (244 bytes minus 64 KB)

Maximum volume size Theory: 264 clusters minus 1 cluster
Implementation: 256 terabytes minus 64 KB ( 232 clusters minus 1 cluster)

Files per volume 4,294,967,295 (232 minus 1 file)

This falls very closely along the lines that I thought you were talkign about. I am a video encoding fr34k. I love it.

And your best bet is to convert your friends drives in their entirety to NTFS if the OS supports it.

You will run intomore problems working with video editing if you are using FAT systems due to the lame limitations that you are stuck with. Not to mention if your friend starts to get into capturing video.

Just one hour of 352-240 MPEG1 will take about 3.5G. Ifyou aren't watching what you're doing you will hit that limit in a few minutes if you decide to take a piss after your show you were dubbing before stopping the capture. If you catch my drift.

Just convert those puppies to NTFS and all will be well. Either that or switch to Linux and go Ext-2. I don't know the specifics on the file sizes there, but I do know it's not stuck with that freakin FAT problem...

Mrafrohead

A 2 gigabyte file is 16 gigabits of payload. A rough estimate of network time at 100Mbps is that you will need 170 seconds to transmit this. This assumes full packet size and IP protocol. TCP will add some additional time for the handshakes - about 10 seconds worth. If you are going across a WAN the time will grow significantly as you factor in latency and smaller pipes.

The good news is that your nodes probably won't be able to process as fast as the 100Mbit LAN can handle, so your delays will be at the nodes. How much? I generally see LAN time at between 1-10 percent of the total time, so this file transfer is likely to be a 27 minute process at best.