even worse over the WAN link, due to latency and likely transmission windowing/checksum overhead. Try an experiment yourself ... Try a copy of one such folder and it's hundreds of files, and see how long it takes ... Then zip the contents, and see how long the copy of the zip file takes ... Bet you'll be pleased at the zip
Erik Goldoff IT Consultant Systems, Networks, & Security -----Original Message----- From: Bryan Garmon [mailto:[email protected]] Sent: Wednesday, May 20, 2009 12:27 PM To: NT System Admin Issues Subject: Re: Anyone using Radiant Systems Aloha Point Of Sale? Thank you for the clarification. This helps me a great deal. The backup is happening (or should I write attempting to happen) across a WAN link. On Wed, May 20, 2009 at 11:17 AM, Erik Goldoff <[email protected]> wrote: > Short answer, if you have 1,000 files of 1mb each, that's 1,000 times > the software ( and drive heads ) have to seek back to the directory > for each filename and physical location pointer on the disk ... So if > you have hundreds of files, you've got to find the file, request open > to read, read the data, request close from read for each one ... In > one larger file, you only have the one request to open to read, and > each block points to the next block to read ... In a way, takes out > a lot of 'handshaking' in the disk I/O process, which is VERY > inefficient > > many if not most of your current files are smaller than your physical > block size, whereas in a single larger file, the entire block could > comprise multiple files worth of data, so more data read for each block request ... > > And lastly, if compressed, the actual resulting file size could end up > much smaller than the size of the combined raw files, if your > transactions files are mostly plain text, compression could be > anywhere from 20% to 80% efficient. Even at *only* 20% efficiency > you'd be reading an 8mb file instead of a 10mb file ( you'd be > displacing the efficiency by the zip and unzip process overhead, but > that wouldn't directly affect your backup program's ability to capture > the file ) > > And you didn't say, is the backup local to the Aloha directory, or are > you traversing some type of WAN link ? > > > > Erik Goldoff > IT Consultant > Systems, Networks, & Security > > > -----Original Message----- > From: Bryan Garmon [mailto:[email protected]] > Sent: Wednesday, May 20, 2009 11:04 AM > To: NT System Admin Issues > Subject: Re: Anyone using Radiant Systems Aloha Point Of Sale? > > What's the link between the file size and the efficiency? I'm fuzzy > when it comes to understanding chunk sizes and bit rates and such. > > > On Wed, May 20, 2009 at 10:59 AM, Erik Goldoff <[email protected]> wrote: >> I know Longhorn Steakhouse used to use Aloha before Darden acquired >> them, not sure if they still do ... But if the backup program has >> problems, wonder if you could script a zip program to encapsulate all >> the files into one larger zip that the backup program might be able >> to stream much more efficiently >> >> >> >> Erik Goldoff >> IT Consultant >> Systems, Networks, & Security >> >> > > > ~ Finally, powerful endpoint security that ISN'T a resource hog! ~ ~ > <http://www.sunbeltsoftware.com/Business/VIPRE-Enterprise/> ~ > > ~ Finally, powerful endpoint security that ISN'T a resource hog! ~ ~ <http://www.sunbeltsoftware.com/Business/VIPRE-Enterprise/> ~ ~ Finally, powerful endpoint security that ISN'T a resource hog! ~ ~ <http://www.sunbeltsoftware.com/Business/VIPRE-Enterprise/> ~
