No.   The current data is already on the base volume.  There's nothing to commit.   Only if you completely restore a volume from a snapshot will there be write to the base volume.  From the Equallogic Support website KB:  Solution Title ARRAY: How snapshot reserve space is allocated and used  Solution Details Snapshot Reserve Allocation and Usage  -------------------------------------  In a PS Series group, snapshots can protect volume data against mistakes,  viruses, or database corruption. A snapshot represents the contents of a volume  at the time you created the snapshot. Creating a snapshot does not disrupt  access to the volume, and the snapshot is instantly available to authorized  iSCSI initiators.  Before you can create snapshots of a volume, you must allocate space (called  snapshot reserve) for the snapshots. You set the value of the snapshot reserve  when you create or modify a volume. Snapshot reserve is allocated from the same  pool as the volume data.  When snapshot data consumes all the snapshot reserve, the group either deletes  the oldest snapshots to free space for new snapshots or sets the volume and  snapshots offline, depending on the policy you selected for recovering snapshot  space.  The functionality used to create snapshots is called hybrid allocate-on-write.  Page Sharing and Snapshot Operation  -----------------------------------  A PS Series group organizes physical storage into logical segments called pages.  Each page consists of multiple logical blocks. This is similar to the way file  systems combine physical disk sectors into "clusters" or "chunks." Each page has  a reference count that records the number of volumes and snapshots that share  the page.  When you create a volume, the group creates an internal table, called the volume  table, that contains pointers to the pages that the volume uses. When you create  a snapshot of a volume, the group creates a snapshot table by making a copy of  the volume table, which is typically an in-memory operation that the group  performs transactionally. For each in-use volume page, the group increases the  reference count to indicate that the volume and snapshot share the page.  Because the group does not move or copy data or allocate new pages, snapshots  are fast and efficient.  Snapshot reserve stores the differences between volume data and snapshot data  (in addition to differences between the data in multiple snapshots). When you  first create a snapshot, the page tables for the volume and snapshot are  identical copies in memory, and the snapshot does not consume any snapshot  reserve. An application reading the same logical block from the volume or the  snapshot returns the same data because the application is reading the same page.  However, if you write to a page that a volume and snapshot share, snapshot  reserve is consumed.  The following is a simplified example of a snapshot operation. Typically, no  additional I/O operations are needed to maintain volume or snapshot data.  However, other internal operations might occur because of virtualization and  data load balancing across PS Series arrays.  If an application performs an 8KB write to a volume that has a snapshot, the  group:  1 - Determines which page is changed by the write operation.  2 - If the page is not shared, writes the data to the page.  3 - If the page is shared:  . a) Allocates one new page from free space and reduces the snapshot reserve for  . the volume by one page.  . b) Updates the volume page table to point to the newly allocated page.  . c) Marks the newly allocated page as having new volume data and references the  . original page for unchanged data.  . d) Writes the data to the new page.  After the write completes, if you read the data from the volume, you access the  new page and the new data. However, if you read the same logical block from the  snapshot, you get the original data, because the snapshot still points to the  original page. Similarly, if you set a snapshot online and write to the snapshot,  hybrid allocate-on-write functionality protects the original volume data by allocating  a new page for the new snapshot data.  Only the first write to a shared volume (or snapshot) page consumes additional  snapshot reserve. Each subsequent write is treated the same as a write to a  non-shared page because the original data is already protected.  Functionality similar to hybrid allocate-on-write is used in cloning operations.  However, unlike when you create a snapshot, cloning a volume immediately  consumes additional group space. If a clone is moved to another pool, the data  is copied during the pool move operation.  Restoring a Volume from a Snapshot  ----------------------------------  Because of the page table design, restoring a volume from a snapshot is very  fast. First, the group automatically creates a snapshot of the volume by copying  the volume table to a new snapshot table. Then, the group swaps the page tables  of the volume and the snapshot that you selected for the restore operation. No  additional space is needed, and no data is moved.  Deleting Volumes and Snapshots  ------------------------------  Because volumes and snapshots share pages, if you delete a volume, you  automatically delete all the snapshots associated with the volume.  You can delete snapshots manually (for example, if you no longer need the  snapshot data). In addition, the group can delete snapshots automatically in the  following situations:  1 - Insufficient free snapshot reserve. If snapshot data consumes all the snapshot  . reserve, the group either deletes the oldest snapshots to free space for new  . snapshots or sets the volume and snapshots offline, depending on the policy  . you selected for recovering snapshot space.  2 - Maximum number of snapshots created from a schedule reached. If you set up a  . schedule for creating snapshots, you can specify the maximum number of  . snapshots that you want to keep. Once the schedule creates the maximum number  . of snapshots, the group will delete the oldest snapshot to allow the schedule  . to create a new snapshot.  Snapshot deletion occurs as a queued background task. The group walks through  the snapshot page table and decrements the reference count on each shared page.  Any page that has a reference count of zero is released to free space. Pages  with a non-zero reference count are not released, because they are shared with  the volume or other snapshots.  Because snapshots might be automatically deleted , if you want to preserve the  data in a snapshot, you can clone the snapshot.  Understanding Snapshot Reserve Usage  ------------------------------------  Snapshot reserve is consumed only if you write to a shared volume or snapshot  page. However, it is difficult to correlate the amount of data written to a  volume (or snapshot) with the amount of snapshot reserve consumed as a result,  especially if you have multiple snapshots.  Because pages consist of multiple logical blocks, I/O size and the distribution  of volume I/O operations affect overall I/O performance in addition to snapshot  reserve usage.  For example, making many writes to a narrow range of logical blocks in a volume  consumes a relatively small amount of snapshot reserve. This is because writing  to the same logical block more than once does not require additional snapshot  reserve.  However, making many random writes across a wide range of logical blocks in a  volume can consume a large amount of snapshot reserve, because many different  pages are affected.  Typically, snapshot reserve consumption depends on the following:  1 - Number of writes that occur to the volume (or snapshot) while at least one  . snapshot exists. In general, more writes tend to use more snapshot reserve,  . although multiple writes to the same logical block do not require additional  . space.  2 - Range of logical blocks over which the writes occur. Writes to a wide range of  . logical blocks tend to use more snapshot reserve than writes to a narrow  . range, because more of the writes are to different pages.  3 - Number of snapshots of the volume and the timing of write operations. The more  . snapshots you create, the more snapshot reserve is needed, unless there are  . few writes to the volume or snapshots.  4 - Snapshot age. Older snapshots tend to consume more snapshot reserve than  . recent snapshots because the group must maintain the original data for a  . longer time.  Sizing Snapshot Reserve  -----------------------  You cannot create snapshots until you reserve snapshot space. Snapshot reserve  is configured as a percentage of the volume reserve (allocated space) for the  volume.  When you create a volume, by default, the volume uses the group-wide snapshot  reserve setting. (The default group-wide snapshot reserve setting is 100%. You  can change this default.) You can change the snapshot reserve setting when you  create a volume or later, even while the volume is in use.  Although snapshot reserve is not used until volume or snapshot writes occur, it  is immediately consumed from free pool space. For example, if you create a  fully-allocated (not thin provisioned) 200GB volume and specify a 50% snapshot  reserve, free pool space is reduced immediately by 300 GB (200 GB for the volume  reserve and 100 GB for snapshot reserve), even though there are no pages in use.  Therefore, before you create a volume, you should consider how much snapshot  reserve, if any, to allocate to the volume. Set the snapshot reserve to zero (0)  if you do not plan to create snapshots.  The optimal size of the snapshot reserve depends on the amount and type of  volume changes and the number of snapshots that you want to retain.  For example, if you set the snapshot reserve to 100% and then create a snapshot,  you can write to every byte in the volume without running out of snapshot  reserve. However, if you create another snapshot and then write to every byte of  the volume, the first snapshot is deleted to free space for the new snapshot. If  you set the snapshot reserve to 200%, there would be sufficient snapshot reserve  for both snapshots.  A very conservative strategy in sizing snapshot reserve is to set the snapshot  reserve value to 100 times the number of snapshots that you want to keep. This  guarantees that you keep at least the desired number of snapshots, regardless of  the number of writes to the volume. However, this strategy typically allocates  an excessive amount of snapshot reserve, because rarely do you overwrite all the  data in a volume during the life span of a snapshot.  The best way to size snapshot reserve is to set the reserve to an initial value  and observe how many snapshots you can keep over a specified time period under a  normal workload. If you are using schedules to create snapshots, allow the  schedule to run for several days.  To obtain an initial value for a volume's snapshot reserve, you must estimate  the amount and type of volume writes and the number of snapshots you want to  keep. For example:  - If you expect few writes or writes that are concentrated in a narrow range of  . logical blocks, and you want to keep only a few snapshots, start with a value  . of 30%.  - If you expect many writes or writes that are random across a wide range of  . logical blocks, and want to keep more than a few snapshots, start with a value  . of 100%.  If snapshots are deleted before you reach the desired number of snapshots,  increase the snapshot reserve percentage. If you reach the desired number of  snapshots without consuming most of the free snapshot reserve, decrease the  snapshot reserve percentage. Continue to monitor snapshot reserve and make  adjustments as needed.  How Thin Provisioning Affects Snapshot Reserve  ----------------------------------------------  Snapshot reserve is based on a percentage of the volume reserve (space allocated  to a volume). For a fully provisioned volume, the volume reserve is equal to the  reported volume size. However, for a thin provisioned volume, the volume reserve  is initially much less than the reported size (default minimum volume reserve is  10% of the reported size) and increases as volume writes occur.  If you change a thin-provisioned volume into a fully provisioned volume, the  amount of snapshot reserve increases automatically, because the volume reserve  increases to the reported volume size.  If you change a volume from fully provisioned to thin-provisioned, the amount of  snapshot reserve decreases automatically, because the volume reserve decreases.  However, if the resulting snapshot reserve will be too small to store all the  existing snapshots, the group automatically increases the snapshot reserve  percentage to a value that preserves all the existing snapshots.  Reducing Snapshot Reserve Usage  -------------------------------  Over time, you can reduce snapshot reserve usage by periodically (for example,  once a month) defragmenting file systems and databases. Defragment operations  try to consolidate the file segments in a volume and, thus, decrease the range  of logical block addresses used in the volume pages.  Defragment operations read data from one location and then write data to a new  location. Therefore, snapshot reserve usage increases during and immediately  after defragmentation, because existing snapshots will use more than the usual  amount of snapshot reserve. However, snapshots created after the defragment  operation should use less snapshot reserve because volume data is more contiguous.  If a volume is very fragmented, the potential reduction in snapshot reserve  usage might be dramatic, particularly after you delete large, pre-defragment  snapshots. Defragment operations can also reduce the I/O load on the group,  because the contiguous data makes I/O operations more efficient, thus improving  overall I/O performance.  Newer defragmenters are good at reducing fragmentation without attempting to be  overly thorough. Some defragmenters also attempt to combine inactive data,  further limiting the likelihood of changes to shared pages. However, do not  defragment too frequently.  Sector alignment can also affect snapshot space utilization, especially in  larger volumes. File systems should be properly sector aligned. This is  described in technical reports for VMware and Windows environments. 
Hello forum I havent been able to confirm this, but do snapshots ever need to commit anything to the base volume? Lets say i have 10 snapshots and it needs to delete the oldest? will there be a IO load to commit snapshot changes? Also if anyone could point me at any type of indepth explaination of this snapshot technique I would be interessted to read all about it. Thanks!      
Question about Equallogic snapshots.