[TriLUG] SAN file locking

Joseph Mack NA3T jmack at wm7d.net
Mon Dec 19 18:14:30 EST 2011


On Mon, 19 Dec 2011, bak wrote:

> With NAS, the NAS controller owns the blocks and the 
> filesystem and has an /etc/exports file.
>
> With SAN, the SAN controller owns the blocks, but not the 
> filesystem. The individual servers connecting to the SAN 
> handle that.

Got it.

This is my original problem/question: I saw it from the 
viewpoint of filelocking, but the bigger picture is who owns 
the blocks? eg where it the partitioning and FS. With 
NAS/DAS the machine that owns the disks writes the 
partitioning and FS info onto the blocks directly. In a SAN 
I imagine the partitioning info could be in a table on the 
host and not on the SAN blocks. Presumably the simplest 
thing would be to write the partition table etc onto the 
physical disk. Perhaps not. Perhaps the metadata should be 
on another disk (isn't this what google is about?)

> Some operating systems are OK with having a read-only 
> filesystem attached. But solutions like this

you mean (ro) solutions?

> for the SAN space are not there, because the problem to be 
> solved would have to be
>
> -- Useful even with a read-only filesystem
> -- Requiring the sort of low-latency performance SAN provides
> -- Not more cheaply and easily deployed with a r/o NFS export

I'm sorry. I don't know what you're trying to say here. I 
don't even get enough to ask you a question about it. Can 
you try again.

> By the way, SAN is not only FC -- iSCSI and Fibre Channel 
> over Ethernet also are considered SAN protocols, since 
> like FC they are basically encapsulated SCSI commands.

yup. The SAN is independant of the physical layer.

> Also with SANs, density varies hugely for performance 
> reasons. Every disk in a SAN has a maximum number of 
> operations per second it can handle. I'm really 
> simplifying here, but all other things being equal, 28 
> drives that are 500GB each are going to be faster than 14 
> drives that are 1TB each. More spinning disks means more 
> disks to satisfy read/write requests.

ah. I saw racks of 150-400GByte disks and I'm thinking these 
are really prehistoric. You could get the same amount of 
storage in a quarter of the disks and use that much less 
power etc. Now I know why you have 28 RAID 6.

> Of course the SAN controller is doing some coordinating 
> behind the scenes to make reads and writes across all 
> those disks as efficient as possible, and there's 
> certainly a point of diminishing returns, but plenty of 
> folks are happy with more disks and less storage for 
> performance reasons.

I see. All obvious after it's explained.

> Of course the introduction of SSD technology is changing 
> the way all this works quite quickly.

Short answer yes, but not so quickly. I remember seeing pci 
boards of flash memory 10yrs ago. Possibly it was only a 
MByte or so back then. It's taken a while to get here.

Joe

-- 
Joseph Mack NA3T EME(B,D), FM05lw North Carolina
jmack (at) wm7d (dot) net - azimuthal equidistant map
generator at http://www.wm7d.net/azproj.shtml
Homepage http://www.austintek.com/ It's GNU/Linux!



More information about the TriLUG mailing list