( ESNUG 509 Item 8 ) -------------------------------------------- [09/13/12]
From [ Karim Khalfan of ClioSoft, Inc. ]
Subject: ClioSoft has doubts about IC Manage's "virtual file" BRCM claims
Hi John,
This IC Manage post by Broadcom seemed a bit too full of marketing Kool-Aid
to go without a rebuttal. Please see my comments below.
> IC MANAGE VIEWS - VIRTUAL FILE DISTRIBUTION SYSTEM
>
> One major downside to IC Manage was it populated each workspace with
> live copies of the data. Since they do not use soft links, the amount
> of disk space that was used can be very large.
>
> IC Manage's fix is its ICM Views -- a virtual file system with local
> caching and disk quota management -- which is its "storage acceleration
> software". When designers fetch their databases from the server, they
> immediately see all their files (and their metadata such as size,
> permissions, and timestamps) but they don't up use any disk space because
> the files are virtual.
>
> - from http://www.deepchip.com/items/0505-05.html
Relying on a third party Software Configuration Management system is indeed
a limiting factor for IC Manage.
Since they have little control of the underlying SCM system, IC Manage has
tried to address the issue of excessive use of disk space by introducing a
"virtual" file system between the SCM system and the operating system.
The idea of a virtual file system is not at all novel.
ClearCase has had a virtual file system since way back in 1992. Perforce,
the SCM system that IC Manage piggybacks on, could have borrowed this idea
but did not. For 20 years no other SCM system felt the need to imitate this
seemingly "cool" virtual file idea.
One would think there are probably some good reasons.
Why would an IT department want to trust a new "virtual" file system? The
file system is a core component of the operating system. The risks and
complications of using a new virtual file system are significant and real.
"The vobs are down" used to be a common reason for long lunches at many
ClearCase sites.
If a virtual file system has a problem the entire design team will have to
shut down whether they are using the DM system or not.
While the "virtual" files may share the same space on disk, your backup SW
will still think the "virtual" files are real. You may have saved on disk
space but not on disk space management overheads.
> ICM Views has 3 main elements:
>
> a. Disk Space Savings and Storage management
>
> A soft-links approach, reduces the size of your read data by linking
> to a mirror on a common network disc. Mirrors can be useful if
> everyone points at the same file versions, however, when the data
> changes, it is automatically pushed onto users. You can avoid this
> by linking to a cache instead, but the disc savings decreases as
> users end up referencing different versions of the design.
>
> Finally, with soft links you must pay close attention to your UNIX
> permissions to avoid unauthorized access.
This IC Manage user is probably basing this discussion on his experience
with his previous DM solution.
Most of ClioSoft's users use links to cache and see significant disk space
savings.
They do not have to worry about UNIX permissions because the cache server
manages the UNIX permissions of the file versions in the cache.
Most users usually want the latest versions, so the cache has just one or
two versions shared by multiple users. Of course, if users want different
versions it will use up more disk space whether you are using links to
cache or a virtual file system.
> ICM Views' virtual files don't have those drawbacks. It allows you to
> populate a virtual workspace anywhere, even on the local disk of the
> host machine. If files are modified, they can be placed on the network
> filer. This lets designers use their local Linux workstations as "cache
> disks". They set the limit on workspace size, then ICM Views rotates
> the least recently used files to stay within that quota, and
> automatically handles the cache management and network connections.
The work space may appear to get created on your local disk in seconds but
bytes are not ruled by the laws of Hogwarts.
When you want to actually read the file the bytes will have to be copied.
You have to pay the piper sometime and in this case you will be nickel-and-
dimed for every file access.
> b. "Zero Time Sync" (ZTS)
>
> ICM Views has a feature called Zero Time Sync that lets you sync up
> your workspaces really fast without any symbolic link limitations.
> We ran a test on ZTS at Broadcom with a 2 GB workspace, and the user
> workspace cache set to 1 GB.
>
> IC Manage GDP + ZTS : 15 seconds
These references to "symbolic link limitations" sounds a bit too much like
marketing speak.
Use of symbolic links are just an open and transparent implementation of
what a "virtual" file system is doing (i.e. pointing multiple users to the
same physical file.) With symbolic links you do not have to mess around
with a brand new and untested virtual file system.
Additionally, backups and management of your workareas will be much faster
because the files do not pretend to exist there.
> c. EDA tool acceleration
>
> ICM Views lets you assign local storage for the reads, and network
> storage for the writes. This means input/output-bound EDA apps
> can run much faster because data is local to the CPU. (The EDA apps
> that I expect to benefit most are ones that do a lot of reads,
> because the reads are now limited by disk access speed instead of
> network speeds, e.g. layout and DRC runs.) This will make it much
> faster to traverse a complex design hierarchy to determine connections.
If a user chooses to use local storage then the bytes have to be copied to
the local disk. There just is no getting around the laws of physics. It is
not that different from creating a local workarea. You have just added the
overhead of a "virtual" file system on top.
- Karim Khalfan
ClioSoft, Inc. Fremont, CA
Join
Index
Next->Item
|
|
