I wouldn't expect a performance difference between reading a 4KB chunk from a small file or from a big file, assuming both are properly implemented.

For your 1GB "huge" file, you could hold an in-memory index containing available filepaths stored in the VFS (or hashes of them, to store space). Each index entry would just contain the offset in the file - a read is a easy seek, just read the part of the file that you need. If you have compression applied, make sure each file is compressed separately or in series of smaller files, so that you can decompress your chosen file with little effort.

From the operating system point of view, it doesn't really make any difference if the files are 5 or 500 MB. Small files, that is below 10KB or so, actually have a negative impact (because finding the file and opening it also takes time).

I don't see any immediate advantage of using small archives instead of one big one, performance wise. In fact, many AAA games use this method of huge monolithic files. 

The "easy patching" argument still applies, but then I guess you don't need any fancy "packer" algorithm.