Re: [LSF/MM TOPIC] linux servers as a storage server - what's missing?

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



On Fri, Dec 23, 2011 at 02:24:42AM +0530, Shyam_Iyer@xxxxxxxx wrote:
> 
> 
> > -----Original Message-----
> > From: linux-scsi-owner@xxxxxxxxxxxxxxx [mailto:linux-scsi-
> > owner@xxxxxxxxxxxxxxx] On Behalf Of Vivek Goyal
> > Sent: Thursday, December 22, 2011 10:59 AM
> > To: Iyer, Shyam
> > Cc: rwheeler@xxxxxxxxxx; linux-fsdevel@xxxxxxxxxxxxxxx; linux-
> > scsi@xxxxxxxxxxxxxxx
> > Subject: Re: [LSF/MM TOPIC] linux servers as a storage server - what's
> > missing?
> > 
> > On Thu, Dec 22, 2011 at 01:44:16PM +0530, Shyam_Iyer@xxxxxxxx wrote:
> > 
> > [..]
> > 
> > > Simple asks -
> > > 1) Provide a consistent storage and fs management library that
> > discourages folks to write their own usespace storage library. Include
> > things like fs formatting(fs profiles), transport configuration(eg:
> > iscsiadm as a library), thin provisioning watermarks, cluster
> > management, apis for cgroups etc.
> >                                       ^^^^^^^^^^^^^^^^
> > For cgroups, we have libcgroup library. Not many people like to use it
> > though as cgroup is exported as a filesystem and they prefer to use
> > normal
> > libc api to traverse and configure cgroups (Instead of going through
> > another library). Some examples include libvrit, systemd.
> > 
> > Thanks
> > Vivek
> 
> Well honestly I think that is a libvirt/systemd issue and libvirt also invokes things like iscsiadm, dcb etc as a binary :-/
> 
> Some one could always use qemu command lines to invoke KVM/XEN but libvirt has saved me one too many days in doing a quick operation without wondering about a qemu commandline.
>  
> I am also asking for ideas on how to avoid this fragmentation because just like libvirt others are also encouraged to do their own libc thing in the absence of a common storage management framework..
> 
> Does the standard interface for linux end at the user/kernel boundary or the user/libc boundary? If so I feel we would continue to lag behind other OSes in features because of the model. 

This is true only for IO cgroup management. There is not much to be done. For
basic management, an applicatoin can just write 500 lines of code and be
done with it.

libcgroup does offer bunch of commnad lines operations too.

Do you have something in mind, what applications expect out of a IO cgroup
library and what other OSes are supporting. Don't extend this libc thing
to iscsi, and other storage management requirements.

Thanks
Vivek 
--
To unsubscribe from this list: send the line "unsubscribe linux-scsi" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html


[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
[Index of Archives]     [SCSI Target Devel]     [Linux SCSI Target Infrastructure]     [Kernel Newbies]     [IDE]     [Security]     [Git]     [Netfilter]     [Bugtraq]     [Yosemite News]     [MIPS Linux]     [ARM Linux]     [Linux Security]     [Linux RAID]     [Linux ATA RAID]     [Linux IIO]     [Samba]     [Device Mapper]
  Powered by Linux