by Marty Foltyn

The Consumer Electronics Show (CES), held each year in early January in Las Vegas, has moved a long way from the days when you had to search high and low on the show floor for storage-related exhibits. Step on the floor in 2016, and you may never get past the automobile displays which have the capability to track and store your every activity. And even if you do, the plethora of accessible tech, video imaging, and smart home apps will make your head spin!

Solid State Storage is an important contributor to the internet of things featured at CES, and understanding it is key to making informed choices. Get ready for CES 2016 by first attending a SNIA Solid State Storage webcast on Friday, December 11 at 11:00 am Pacific where Tom Coughlin, CEO of analyst firm Coughlin Associates, presents Flash Memory Enables 4K and Beyond Video Workflows.

As the price and availability of flash memory grows flash memory will enable future generations of media that is even more immersive than today as video moves to 8K and virtual reality begins to play an increasing role in entertainment. Tom will discuss how, as the resolution and frame rate for video increase, flash memory is staring to play a significant role for content capture, post production and content delivery. His presentation will include material from the 2015 Digital Storage in Media and Entertainment Report from Coughlin Associates (and the associated 2015 digital media professional survey) on the growing use of flash memory in all aspects of professional media and entertainment and put flash use in context with other storage technologies in this industry.

The webcast is an important lead in to the CES partner program Storage Visions Conference January 3-4 in Las Vegas, where SNIA will exhibit  solid state and persistent memory and have a pre-conference education day.  Register for this informative SNIA Brighttalk webcast , held on December 11, 2015 at 11:00 apm Pacific/2:00 pm Eastern at https://www.brighttalk.com/webcast/663/180197

Non-Volatile Memory Express (NVMe) has piqued the interest of many people in the storage world. Using a robust, efficient, and highly flexible transportation protocol for SSDs, Flash, and future Non-Volatile Memory storage devices, the NVM Express group is working on extending these advantages over a networked Fabric.

Our first Webcast on The Performance Impact of NVMe over Fabrics was very well received. If you missed it, check-it out on-demand. On December 15^th, Dave Minturn, Storage Architect at Intel, will join me for a deeper dive in a live Webcast, “Under the Hood with NVMe over Fabrics.” At this Webcast we’ll explain not only what NVMe over Fabrics is, but also specifically pay attention to how it works. We’ll be exploring:

• Key terms and concepts
• Differences between NVMe-based fabrics and SCSI-based fabrics
• Practical examples of NVMe over Fabrics solutions
• Important future considerations

Register now and join us as we discuss the next iteration of NVMe. I hope to “see” you on the 15^th when Dave and I will be anxious to answer your questions.

Non-Volatile Memory Express (NVMe) has piqued the interest of many people in the storage world. Using a robust, efficient, and highly flexible transportation protocol for SSDs, Flash, and future Non-Volatile Memory storage devices, the NVM Express group is working on extending these advantages over a networked Fabric. Our first Webcast on The Performance Impact of NVMe over Fabrics was very well received. If you missed it, check-it out on-demand. On December 15^th, Dave Minturn, Storage Architect at Intel, will join me for a deeper dive in a live Webcast, "Under the Hood with NVMe over Fabrics." At this Webcast we'll explain not only what NVMe over Fabrics is, but also specifically pay attention to how it works. We'll be exploring:

• Key terms and concepts
• Differences between NVMe-based fabrics and SCSI-based fabrics
• Practical examples of NVMe over Fabrics solutions
• Important future considerations

Register now and join us as we discuss the next iteration of NVMe.  I hope to "see" you on the 15^th when Dave and I will be anxious to answer your questions. Update: If you missed the live event, it's now available  on-demand. You can also  download the webcast slides.

We got a lot of great questions at our recent Ethernet Storage Forum webcast “The Life of a Storage Packet (Walk).” As promised, we’ve compiled all the questions with fairly detailed answers. We hope this blog helps to clear up any confusion or uncertainties. If you think of additional questions, please comment below and we’ll get back to you as soon as we can. Thanks to everyone who watched the live webcast. If you missed it, it’s now available on-demand.

Q. Does size of a block depend on OS?

A. Yes, some OS’ only support 512 byte blocks. Some OS’ provide a method to support both 512 byte blocks and 4096 (aka 4K) byte blocks; for example, via a qualifier in their format command. Some devices are built using 4K block sizes, but then emulate 512 byte blocks to the host (aka 512E devices). Many modern versions of OS’ automatically detect the block size of each device they discover and do the right thing based on what they discover. You have to check the documentation for your OS to know its capabilities.

Q. CIFS is not a file system.

A. Not in the same way that ext, ntfs, FAT, HFS, UFS, etc. are, no. However, in terms of certain functionalities that we discussed on the presentation – that is, the ability to manipulate files with operations such as read, write, create, delete, and rename – are all file system functionalities. The difference being, of course, that the files are not on the local computer and are actually on a remote computer.

For what it’s worth, the term ‘CIFS’ has been deprecated from usage, and SMB is the preferred term for precisely the reasons that it should not be confused with local OS systems like the ones mentioned above.

Q. Is it safe to say that a “block” at the file system level is equal to an IO?

A. Not specifically. The difference in the use of those terms, is that a “block” is a place that data is stored – it has an address and it contains data (512 byte of data or 4K bytes of data). An IO is an operation that requests access to a block. An IO may perform a read operation on a block, or it may perform a write operation on a block.

Remember, the term IOPS is I/O operations per second – so it is not about blocks or bytes or bits – it is operations. If the operations are performed on a 512 byte block, they produce a different number of MB/sec than if they operate on a 4K byte block.

So, let’s take an example. A 1MB/second bandwidth on a 4K block size device is the same speed as 1MB/second bandwidth on a 512 byte block size device (observe, however, that the 4K block size device will have only 1/8 the IOPS that the 512 byte device has – because it will take only 1/8 the operations to transfer the same number of Mega-bytes). However, 1M IOPS on a 4K block size device is much better than 1M IOPS on a 512 byte block size device (because the 4K block size device is moving 8X the amount of data than the 512 byte block size device in each operation.

There is an excellent explanation and walk-through of IOPS in our Storage Performance Benchmarking webinar.

Q. Don’t all those Inodes also live on the disk and so don’t the IOs to read those blocks also have to go to the SCSI controller?

A. Well-spotted!

The communication back and forth between the file system and the Inodes traverses the controller for all access to blocks on disk. This is one of the reasons why needing to access disk is considered “expensive.” When you add in a network to the mix, these kinds of situations need particular careful consideration.

Q. Shall we allocate blocks and inodes or is it an automatic process?

A. It’s an automated process, and there is no user intervention at all.

Q. Are Inodes created during OS installation?

A. Inodes are a particular block type, among some other block types (e.g., data blocks, boot blocks, superblocks, group descriptor blocks). These block types are combined into functional groups. These groups are OS-dependent. The block layout therefore, including Inodes, is created during OS installation. If the filesystem needs more Inodes after the OS installation, the OS dynamically adds them to the Inode pool.

Q. Which physical hardware does volume manager reside?

A. Volume managers are not hardware. They are software layers that create pseudo devices that are presented to layers of the OS above them (typically to the file system layer). The volume manager software fits into the OS to accept requests from the file system and pass those requests down to the device driver. In some systems they might be called “filter drivers”.

Q. In flash media, is there also an iSCSI controller that converts PCIe into iSCSI to interact with the flash?

A. I want to make sure that the answer to the question is clear.

On the host, we need to convert PCIe commands to SCSI, so we send them to an iSCSI controller/adapter to be sent across the Ethernet wire. . That adapter can be either software or hardware.

Flash drives are basic media, just like spinning disk drives. Flash will have its own controller, which can be SCSI. If you wish to access the drive over Ethernet using the iSCSI protocol, you will have an adapter on the flash drive (which can be either software or hardware) that will do the SCSI translation between the Flash media and the SCSI commands. This is often called the FTL – or the flash translation layer. Again, the SCSI commands are translated into an Ethernet-friendly packet to be sent along the wire.

There are other types of communication forms for working with Flash, too. The most recent is NVMe. You can see the SNIA webinar on The Performance Impact of NVMe and NVMe over Fabrics for more information.

Q. Why is there a SCSI language in between Storage and the hosts?

A. Before storage standards (like SCSI and ATA), you would purchase storage from Vendor X, and you would also buy a storage controller for that vendor X storage.  If you wanted Vendor Y storage, you could not use the vendor X controller, you had to purchase a new controller from vendor Y. Every vendor had their own language, and you had to purchase matching components.  Once you got locked into one vendor, you were stuck – at the hardware level.

Today with standards (such as SCSI), you can buy a SCSI device from any vendor and connect it to any storage controller that you buy from any vendor – and it just works.  That is the point of the SCSI standard. When the storage standardization efforts began, there were many competing ideas. It just so happened that SCSI won out, and so now it’s everywhere.

Q. If the storage side is flash, do we still need a SCSI controller between host and flash storage or is the controller different for a flash storage?

Yes… and no.

Yes, to use the SCSI part of the OS, the flash device must continue to speak the SCSI protocol and so a SCSI controller is needed. This method of communicating with flash devices enables all the existing S/W on the host OS to just continue working without even knowing it is flash.

No, flash memory chips can be connected to the system using non-SCSI methods. Most of those methods are generally special purpose applications and so the existing OS S/W simply cannot use that device (only the special purpose S/W designed for that device can use it). However, NVMe is a new protocol that is enabling more general use of the flash memory technology with the hopes to provide new capabilities that are beyond what SCSI provides. This is also discussed in our webcast on The Performance Impact of NVMe and NVMe over Fabrics.

Q. What’s the difference between partition, logical disk, volume, LUN, etc?

Excellent question!

Let’s work this one backwards – LUN – that is a SCSI term (actually an acronym) that refers to the Logical Unit Number – it is part of the address used to access a logical unit. Small SCSI devices (such as a single spindle disk drive) have only a single logical unit. Large storage arrays may contain 100s of logical units. Each of those logical units appears to the host OS as if it were a single spindle disk. So, the logical unit is the SCSI object that contains the blocks where the data is stored (where that object may be an individual piece of hardware, or a logical entity within a larger SCSI device). To access a SCSI logical unit, the OS must specify the address of the SCSI device, and then the LUN (logical unit number) for the logical unit within that SCSI device.

The other terms (partition, logical disk, and volume) are OS terms that have to do with virtualization and how the storage blocks are managed. When a SCSI (or other storage device) is formatted by the OS, it may be broken into multiple partitions. Each partition is then treated by the OS as if it were a unique device (a virtual device, or a logical disk). Each of those partitions may then be used independently.

For example, on a Unix system, the “a” partition may contain a file system that has all the files that are necessary to boot. The “b” partition may be setup without a file system and used as the swap or paging storage for use by the virtual memory subsystem. The “d” partition may then contain a file system that contains all the user’s data files. Each partition is unique storage space and may even use a different file system to organize the data located there.

Notice, that I skipped the “c” partition. That partition is often setup to access all the blocks of the physical device. So, on a 500GB disk, maybe “a” contains 10GB, “b” contains 90GB, and “d” contains 400GB; while “c” contains all 500GB. Partitions “a” and “d” may be backed up or restored independently, and partition “c” may be used to perform an image copy of the entire device.

Now, to the other terms:

Logical disk and volume are terms often related to volume managers.

• Logical disk may be a term used to refer to a partition, but usually that is not the case. Logical disks are typically the devices created by the volume management layer when they combine individual devices into a single larger device (a.k.a. a logical disk).
• Volume managers also may be used to divide up a large device into small chunks (just like partitions), and those smaller chunks are referred to as logical disks.
• Volume is a more vague term that typically is used as another term for a logical disk. In some circles, the term Volume is used to refer to a RAID set in a SCSI storage controller (but this is a much less often used definition for Volume).

Q. Will the “complete” presentation somewhere we can go review?

Yes. Click here to access the on-demand webcast as well as a PDF of the webcast slides

We got a lot of great questions at our recent Ethernet Storage Forum webcast "The Life of a Storage Packet (Walk)." As promised, we've compiled all the questions with fairly detailed answers. We hope this blog helps to clear up any confusion or uncertainties. If you think of additional questions, please comment below and we'll get back to you as soon as we can. Thanks to everyone who watched the live webcast. If you missed it, it's now available on-demand. Q. Does size of a block depend on OS? A. Yes, some OS' only support 512 byte blocks. Some OS' provide a method to support both 512 byte blocks and 4096 (aka 4K) byte blocks; for example, via a qualifier in their format command. Some devices are built using 4K block sizes, but then emulate 512 byte blocks to the host (aka 512E devices). Many modern versions of OS' automatically detect the block size of each device they discover and do the right thing based on what they discover. You have to check the documentation for your OS to know its capabilities. Q. CIFS is not a file system. A. Not in the same way that ext, ntfs, FAT, HFS, UFS, etc. are, no. However, in terms of certain functionalities that we discussed on the presentation – that is, the ability to manipulate files with operations such as read, write, create, delete, and rename – are all file system functionalities. The difference being, of course, that the files are not on the local computer and are actually on a remote computer. For what it's worth, the term ‘CIFS' has been deprecated from usage, and SMB is the preferred term for precisely the reasons that it should not be confused with local OS systems like the ones mentioned above. Q. Is it safe to say that a "block" at the file system level is equal to an IO? A. Not specifically. The difference in the use of those terms, is that a "block" is a place that data is stored – it has an address and it contains data (512 byte of data or 4K bytes of data). An IO is an operation that requests access to a block. An IO may perform a read operation on a block, or it may perform a write operation on a block. Remember, the term IOPS is I/O operations per second – so it is not about blocks or bytes or bits – it is operations. If the operations are performed on a 512 byte block, they produce a different number of MB/sec than if they operate on a 4K byte block. So, let's take an example. A 1MB/second bandwidth on a 4K block size device is the same speed as 1MB/second bandwidth on a 512 byte block size device (observe, however, that the 4K block size device will have only 1/8 the IOPS that the 512 byte device has – because it will take only 1/8 the operations to transfer the same number of Mega-bytes). However, 1M IOPS on a 4K block size device is much better than 1M IOPS on a 512 byte block size device (because the 4K block size device is moving 8X the amount of data than the 512 byte block size device in each operation. There is an excellent explanation and walk-through of IOPS in our Storage Performance Benchmarking webinar. Q. Don't all those Inodes also live on the disk and so don't the IOs to read those blocks also have to go to the SCSI controller? A. Well-spotted! The communication back and forth between the file system and the Inodes traverses the controller for all access to blocks on disk. This is one of the reasons why needing to access disk is considered "expensive." When you add in a network to the mix, these kinds of situations need particular careful consideration. Q. Shall we allocate blocks and inodes or is it an automatic process? A. It's an automated process, and there is no user intervention at all. Q. Are Inodes created during OS installation? A. Inodes are a particular block type, among some other block types (e.g., data blocks, boot blocks, superblocks, group descriptor blocks). These block types are combined into functional groups. These groups are OS-dependent. The block layout therefore, including Inodes, is created during OS installation. If the filesystem needs more Inodes after the OS installation, the OS dynamically adds them to the Inode pool. Q. Which physical hardware does volume manager reside? A. Volume managers are not hardware. They are software layers that create pseudo devices that are presented to layers of the OS above them (typically to the file system layer). The volume manager software fits into the OS to accept requests from the file system and pass those requests down to the device driver. In some systems they might be called "filter drivers". Q. In flash media, is there also an iSCSI controller that converts PCIe into iSCSI to interact with the flash? A. I want to make sure that the answer to the question is clear. On the host, we need to convert PCIe commands to SCSI, so we send them to an iSCSI controller/adapter to be sent across the Ethernet wire. . That adapter can be either software or hardware. Flash drives are basic media, just like spinning disk drives. Flash will have its own controller, which can be SCSI. If you wish to access the drive over Ethernet using the iSCSI protocol, you will have an adapter on the flash drive (which can be either software or hardware) that will do the SCSI translation between the Flash media and the SCSI commands. This is often called the FTL – or the flash translation layer. Again, the SCSI commands are translated into an Ethernet-friendly packet to be sent along the wire. There are other types of communication forms for working with Flash, too. The most recent is NVMe. You can see the SNIA webinar on The Performance Impact of NVMe and NVMe over Fabrics for more information. Q. Why is there a SCSI language in between Storage and the hosts? A. Before storage standards (like SCSI and ATA), you would purchase storage from Vendor X, and you would also buy a storage controller for that vendor X storage.   If you wanted Vendor Y storage, you could not use the vendor X controller, you had to purchase a new controller from vendor Y. Every vendor had their own language, and you had to purchase matching components.   Once you got locked into one vendor, you were stuck – at the hardware level. Today with standards (such as SCSI), you can buy a SCSI device from any vendor and connect it to any storage controller that you buy from any vendor – and it just works.   That is the point of the SCSI standard. When the storage standardization efforts began, there were many competing ideas. It just so happened that SCSI won out, and so now it's everywhere. Q. If the storage side is flash, do we still need a SCSI controller between host and flash storage or is the controller different for a flash storage? Yes... and no. Yes, to use the SCSI part of the OS, the flash device must continue to speak the SCSI protocol and so a SCSI controller is needed. This method of communicating with flash devices enables all the existing S/W on the host OS to just continue working without even knowing it is flash. No, flash memory chips can be connected to the system using non-SCSI methods. Most of those methods are generally special purpose applications and so the existing OS S/W simply cannot use that device (only the special purpose S/W designed for that device can use it). However, NVMe is a new protocol that is enabling more general use of the flash memory technology with the hopes to provide new capabilities that are beyond what SCSI provides. This is also discussed in our webcast on The Performance Impact of NVMe and NVMe over Fabrics. Q. What's the difference between partition, logical disk, volume, LUN, etc? Excellent question! Let's work this one backwards – LUN – that is a SCSI term (actually an acronym) that refers to the Logical Unit Number – it is part of the address used to access a logical unit. Small SCSI devices (such as a single spindle disk drive) have only a single logical unit. Large storage arrays may contain 100s of logical units. Each of those logical units appears to the host OS as if it were a single spindle disk. So, the logical unit is the SCSI object that contains the blocks where the data is stored (where that object may be an individual piece of hardware, or a logical entity within a larger SCSI device). To access a SCSI logical unit, the OS must specify the address of the SCSI device, and then the LUN (logical unit number) for the logical unit within that SCSI device. The other terms (partition, logical disk, and volume) are OS terms that have to do with virtualization and how the storage blocks are managed. When a SCSI (or other storage device) is formatted by the OS, it may be broken into multiple partitions. Each partition is then treated by the OS as if it were a unique device (a virtual device, or a logical disk). Each of those partitions may then be used independently. For example, on a Unix system, the "a" partition may contain a file system that has all the files that are necessary to boot. The "b" partition may be setup without a file system and used as the swap or paging storage for use by the virtual memory subsystem. The "d" partition may then contain a file system that contains all the user's data files. Each partition is unique storage space and may even use a different file system to organize the data located there. Notice, that I skipped the "c" partition. That partition is often setup to access all the blocks of the physical device. So, on a 500GB disk, maybe "a" contains 10GB, "b" contains 90GB, and "d" contains 400GB; while "c" contains all 500GB. Partitions "a" and "d" may be backed up or restored independently, and partition "c" may be used to perform an image copy of the entire device. Now, to the other terms: Logical disk and volume are terms often related to volume managers.

• Logical disk may be a term used to refer to a partition, but usually that is not the case. Logical disks are typically the devices created by the volume management layer when they combine individual devices into a single larger device (a.k.a. a logical disk).
• Volume managers also may be used to divide up a large device into small chunks (just like partitions), and those smaller chunks are referred to as logical disks.
• Volume is a more vague term that typically is used as another term for a logical disk. In some circles, the term Volume is used to refer to a RAID set in a SCSI storage controller (but this is a much less often used definition for Volume).

Q. Will the "complete" presentation somewhere we can go review? Yes. Click here to access the on-demand webcast as well as a PDF of the webcast slides Update: If you missed the live event, it's now available  on-demand. You can also  download the webcast slides.

Demand for software-defined infrastructure (SDI) is on the rise, and with good reason. SDI helps data centers meet the challenges of cloud computing, big data/analytics, mobility and social media, in an agile and cost-effective way.  I’m pleased to announce that SNIA will be an active participant at next week’s Software-Defined Infrastructure Summit in Santa Clara, CA, December 1-3.

My colleagues and I at the SNIA Cloud Storage Initiative have organized a “Working with OpenStack” Seminar that kicks off the Summit on Tuesday, December 1.

I will keynote an OpenStack fireside chat along with Chris DePuy, VP, at Dell’Oro Group. We’ll be discussing the SNIA Cloud Data Management Interface (CDMI) and its interface with OpenStack, OpenStack implementations, how standards play, and the future of open source in the 21st century.

My keynote will be accompanied by additional SNIA talks in the Introduction to OpenStack session and the Application Management session:

• Sam Fineberg, PhD, SNIA Cloud Storage Initiative member and Distinguished Technologist at Hewlett Packard Enterprise Storage, will provide an overview of the storage aspects of OpenStack including the core projects for block storage (Cinder) and object storage (Swift), and the new shared file service (Manila). He’ll cover some common configurations and use cases for these technologies, and discuss how they interact with the other parts of OpenStack.
• Richelle Ahlvers, SNIA Open Source Task Force member and Principal Storage Management Architect at Avago Technologies, will discuss application integration in OpenStack and how SNIA-developed standards enable cross-vendor management interoperability and help open source projects interoperate with more industry solutions.

Tuesday’s Seminar day will include additional sessions from leaders in OpenStack, Ceph, and Software Defined Storage. SDI Summit days 2 and 3 will provide information on hardware, software, and data center technology and applications of software-defined infrastructure featuring keynotes from IBM, Intel, Red Hat, and VMware, all SNIA member companies.  It’s a must attend event.

SNIA will also be exhibiting at the Summit. Please stop by booth #408 to learn how SNIA standards are used in open source projects including cloud data management, non-volatile memory, self-contained information retention, and storage management. We will also have information on SNIA programs such as membership, certification, conformance testing, and conferences.

SNIA members and colleagues can use the code SPGP to receive a $100 discount on any level of SDI Summit registration. I hope to see you in Santa Clara!

Demand for software-defined infrastructure (SDI) is on the rise, and with good reason. SDI helps data centers meet the challenges of cloud computing, big data/analytics, mobility and social media, in an agile and cost-effective way.  I’m pleased to announce that SNIA will be an active participant at next week’s Software-Defined Infrastructure Summit in Santa Clara, CA, December 1-3. My colleagues and I at the SNIA Cloud Storage Initiative have organized a "Working with OpenStack" Seminar that kicks off the Summit on Tuesday, December 1. I will keynote an OpenStack fireside chat along with Chris DePuy, VP, at Dell’Oro Group. We’ll be discussing the SNIA Cloud Data Management Interface (CDMI) and its interface with OpenStack, OpenStack implementations, how standards play, and the future of open source in the 21st century. My keynote will be accompanied by additional SNIA talks in the Introduction to OpenStack session and the Application Management session:

• Sam Fineberg, PhD, SNIA Cloud Storage Initiative member and Distinguished Technologist at Hewlett Packard Enterprise Storage, will provide an overview of the storage aspects of OpenStack including the core projects for block storage (Cinder) and object storage (Swift), and the new shared file service (Manila). He’ll cover some common configurations and use cases for these technologies, and discuss how they interact with the other parts of OpenStack.
• Richelle Ahlvers, SNIA Open Source Task Force member and Principal Storage Management Architect at Avago Technologies, will discuss application integration in OpenStack and how SNIA-developed standards enable cross-vendor management interoperability and help open source projects interoperate with more industry solutions.

Tuesday's Seminar day will include additional sessions from leaders in OpenStack, Ceph, and Software Defined Storage. SDI Summit days 2 and 3 will provide information on hardware, software, and data center technology and applications of software-defined infrastructure featuring keynotes from IBM, Intel, Red Hat, and VMware, all SNIA member companies.  It's a must attend event. SNIA will also be exhibiting at the Summit. Please stop by booth #408 to learn how SNIA standards are used in open source projects including cloud data management, non-volatile memory, self-contained information retention, and storage management. We will also have information on SNIA programs such as membership, certification, conformance testing, and conferences. SNIA members and colleagues can use the code SPGP to receive a $100 discount on any level of SDI Summit registration. I hope to see you in Santa Clara!

Data Privacy vs. data protection has become a heated debate in businesses around the world as governments across the globe are proposing and enacting strong data privacy and data protection regulations. Join us on November 18th for our next Cloud Storage live Webcast “Data Privacy vs. Data Protection: The Impact of International Data Protection Legislation on the Cloud.”

Mandating frameworks that include noteworthy changes like defining a data breach to include data destruction, adding the right to be forgotten, mandating the practice of breach notifications, and many other new elements are literally changing the rules when it comes to data protection. The implications of this, and other proposed legislation, on how the cloud can be utilized for storing data are significant. Join this live Webcast to hear:

• “Directives” vs. “regulation”
• General data protection regulation summary
• How personal data has been redefined
• Substantial financial penalties for non-compliance
• Impact on data protection in the cloud
• How to prepare now for impending changes

Our experts, Bob Plumridge, SNIA Europe Board Member; Eric Hibbard, Chair SNIA Security TWG, and I will all be available to answer your questions during the event. I encourage you to register today for this timely discussion. We hope to see you on November 18^th!

Data Privacy vs. data protection has become a heated debate in businesses around the world as governments across the globe are proposing and enacting strong data privacy and data protection regulations. Join us on November 18th for our next Cloud Storage live Webcast “Data Privacy vs. Data Protection: The Impact of International Data Protection Legislation on the Cloud.” Mandating frameworks that include noteworthy changes like defining a data breach to include data destruction, adding the right to be forgotten, mandating the practice of breach notifications, and many other new elements are literally changing the rules when it comes to data protection. The implications of this, and other proposed legislation, on how the cloud can be utilized for storing data are significant. Join this live Webcast to hear:

• "Directives” vs. “regulation”
• General data protection regulation summary
• How personal data has been redefined
• Substantial financial penalties for non-compliance
• Impact on data protection in the cloud
• How to prepare now for impending changes

Our experts, Bob Plumridge, SNIA Europe Board Member; Eric Hibbard, Chair SNIA Security TWG, and I will all be available to answer your questions during the event. I encourage you to register today for this timely discussion. We hope to see you on November 18^th!

Wonder how storage really works? When we talk about “Storage” in the context of data centers, it can mean different things to different people. Someone who is developing applications will have a very different perspective than someone who is responsible for managing that data on some form of media. Moreover, someone who is responsible for transporting data from one place to another has their own view that is related to, and yet different from, the previous two.

Add in virtualization and layers of abstraction, from file systems to storage protocols, and things can get very confusing very quickly. Pretty soon people don’t even know the right questions to ask! That’s why we’re hosting our next SNIA Ethernet Storage Webcast, “Life of a Storage Packet (Walk).”

Join us on November 19^th to learn how applications and workloads get information. Find out what happens when you need more of it, or faster access to it, or move it far away. This Webcast will take a step back and look at “storage” with a “big picture” perspective, looking at the whole piece and attempting to fill in some of the blanks for you. We’ll be talking about:

• Applications and RAM
• Servers and Disks
• Networks and Storage Types
• Storage and Distances
• Tools of the Trade/Offs

The goal of the Webcast is not to make specific recommendations, but equip you with information that will help you ask the relevant questions, as well as get a keener insight to the consequences of storage choices. As always, this event is live, so please bring your questions, we’ll answer as many as we can on the spot. I encourage you to register today. Hope to see you on November 19^th!