I need an iscsi target over S3QL in linux...

[Amos T]

Yes I know the difference between a files and folders and a block device...

But I just wonder if it could be possible with some tweaking...

Seen s3ql is a fuse filesystem system and it is uses blocks, cached or remote...

Would it be possible to provide an extention s3ql to assign a mounted s3ql

system as ISCSI target?

In this regard I think to something such as s3ql provides a 'virtual disk size'

that is <parameter> GB larger then the total unencrypted/uncompressed

blocks of the s3ql filesystem, with 'virtual' heads/sectors/blocksize/alignment

and 'filesystem'...Or by using a 2nd cache sparse diskfile...

Doing this way, I could be able exclude nfs/smb sharing of a mounted S3ql filesystem

and use ISCSI which has many benefits...

Or can I do this with existing technology on linux?

[Daniel Jagszent]

Amos T schrieb am 04.10.21 um 13:48:

> Or can I do this with existing technology on linux?

I know next to nothing about iSCSI but it looks like you could just use
a file on the S3QL file system as FILEIO backstore:
http://www.linux-iscsi.org/wiki/LIO#Backstores

[Amos T]

No, I do not want to use a file inside a S3QL file system.

I look to access s3ql as a block device/Volume/LUN

Op dinsdag 5 oktober 2021 om 15:25:23 UTC+2 schreef dan...@jagszent.de:

[Daniel Jagszent]

Amos T schrieb am 05.10.21 um 18:31:

No, I do not want to use a file inside a S3QL file system.

I look to access s3ql as a block device/Volume/LUN

That's not possible. And I think it would require quite some hacking to make it possible (e.g. block devices have a bound overall size and a static block size – S3QL does not; fuse cannot be used). Why don't you want to use a file on a S3QL filesystem? (E.g. something like df if=/dev/zero of=/path/to/a/file bs=10M count=1048576 to create a 10TB file to host your LUN. Thanks to deduplication it will take up virtually no space and will grow incrementally).

[Amos T]

Of course this would work....

But that would be a raw disk file that holds on it's turn a filesystem (like a virtual drive) that is maintained inside another file (s3ql)

It think it would be a nice feature to extend s3ql so the metafiles of s3ql can handle block devices.  So nesting is not that deep AND additional there can be a way

to provide some little parity on that block device....

In ZFS you have inside Your zpool, a ZFS filesystem, however inside ZFS you are also able to create a ZFS volume with a specific size

that acts as a block device.  That block device can be used as an iscsi target.

ref: https://docs.oracle.com/cd/E19253-01/819-5461/gaypf/index.html

It would be nice to have a s3ql variant as well, this would make it possible to use the s3ql 'volume' as an iscsi target

Currently the s3ql filesystem is build like this:
#mkfs.s3ql [options] <storage url>

So this part is the filesystem approach..

I propose to have also:

#mkvol.s3ql [options] <storage url>

Where You can define in the options the size, heads, parity (some percent or none)

When you mount that 'volume' it is a lun you can use in an iscsi target...

Using different storage url (not always in the same s3 space) in volume creation could create a way to setup a raid/zfs using those luns as (virtual) disks

Op woensdag 6 oktober 2021 om 15:06:51 UTC+2 schreef dan...@jagszent.de:

[Daniel Jagszent]

[...]In ZFS you have inside Your zpool, a ZFS filesystem, however inside ZFS you are also able to create a ZFS volume with a specific size

that acts as a block device.  That block device can be used as an iscsi target.

ref: https://docs.oracle.com/cd/E19253-01/819-5461/gaypf/index.html

It would be nice to have a s3ql variant as well, this would make it possible to use the s3ql 'volume' as an iscsi target [...]

AFAIK you cannot do that with FUSE (the basis behind S3QL). Or any other file system besides ZFS. ZFS is not only a file system but also – amount other things – a NFS, CIFS and iSCSI Server (on Solaris systems, that is).

If you really want to do this, you need to implement a NBD ( https://nbd.sourceforge.io/ ) server and use nbd-client to get a kernel block device for it. This block device then can be used as an iSCSI target.
NBDKit helps with that: https://github.com/libguestfs/nbdkit/blob/master/docs/nbdkit-loop.pod
You could fork S3QL and re-use some parts of S3QL ( https://github.com/libguestfs/nbdkit/blob/master/plugins/python/nbdkit-python-plugin.pod ) but I doubt that S3QL itself will ever have this functionality build in.

[Amos T]

I know s3ql development is a bit lazy in terms of new features...

In terms of storage there is compression and deduplication, however in some use cases

not storage is the main importance but security of data and the ability to have redundant data

you can recover in case of disaster...

I want to see one day parity over stored blocks in s3ql, in case of problem, the parity can fix the block...

And I know there is no feature yet to define block devices in s3ql except you create indeed a raw file inside

a s3ql filesystem.

But the use case to have a block device handled by s3ql as suggested would be a great feature.

I do see already a commercial solution done by cloudbd (.io) so I am not the only one who think in that direction....

nbd is not that complicated to be integrated as you say in s3ql...  a s3ql has not to be limited to a fuse filesystem.

The second usage can be a block device based on the same principles....and hopefully extended with some parity...

Op zondag 10 oktober 2021 om 19:57:34 UTC+2 schreef dan...@jagszent.de: