Re: [lustre-devel] RFC: Spill device for Lustre OSD

--===============4765799903348919190==
Content-Type: multipart/signed;
 boundary="Apple-Mail=_CFD9DCE0-39DB-4B7C-83B6-1A80F1DA3B31";
 protocol="application/pgp-signature"; micalg=pgp-sha256


--Apple-Mail=_CFD9DCE0-39DB-4B7C-83B6-1A80F1DA3B31
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain;
	charset=utf-8


Timothy Day <[email protected]> wrote:
>>>> I haven=E2=80=99t seen any mention of failover yet in this =
conversation (may have missed it), but if the device is truly local, =
then in failed over configurations the data is inaccessible.  If it=E2=80=99=
s *not* local, why not just make the device part of the OST or an =
independent OST?
>>>=20
>>> It won't be local. Actually, this is designed for the cloud.
>>=20
>> I don't understand how 'local' is being used. Cloud or not, all of =
the
>> Lustre client, servers, and backend storage service will be =
co-located
>> in the same data center. I think Patrick is asking whether the spill
>> device will be physically connected to OSS server, or be provided =
over
>> something like SAN? Either way, presenting this device as an =
independent
>> OST brings back the pain of manually managing data placement from the
>> client - which this design is trying to avoid.
>>=20
>>> We already have tiered storage based on mirroring; however, that =
still requires clients to move data and a file system level scanner to =
decide which files move to the cold tier. It's cumbersome to maintain =
those clients.
>>=20
>> Agree, it's not ideal.

Regardless of how the spill device is implemented, there will need to be
some scanning of the front OSD device to find/manage objects to mirror
and release.  This could be done directly on the OST with something like
DDN's lipe_find3 utility, or older scanners like lester, zester, e2scan,
etc. that scan the local ldiskfs block device directly.

If the overhead of a local Lustre mount on the OSS is problematic, that
seems like something which could/should be fixed?  The local mounts are
already "non-recoverable" so that they do not get an entry in last_rcvd
and their absence does not cause any recovery issues.

The main issue we've seen with local mountpoints is that this can =
confuse
HA and prevent Lustre module unloading if they are not taken into =
account
during cleanup.

Cheers, Andreas






--Apple-Mail=_CFD9DCE0-39DB-4B7C-83B6-1A80F1DA3B31
Content-Transfer-Encoding: 7bit
Content-Disposition: attachment;
	filename=signature.asc
Content-Type: application/pgp-signature;
	name=signature.asc
Content-Description: Message signed with OpenPGP

-----BEGIN PGP SIGNATURE-----
Comment: GPGTools - http://gpgtools.org

iQIzBAEBCAAdFiEEDb73u6ZejP5ZMprvcqXauRfMH+AFAmkKkOEACgkQcqXauRfM
H+B1WA/9GOZTaF+O/tDNieheQUXL/60uKzKtzruU4tL1fkDsmggal1+mfpR16+6u
5zq5DRcDlzPYw3xsdD/39iAOr6JocLabUZ2mVWT0ILRXsXY8scyOKYCOigvYxXi0
I2CBnZBMZhfnuX1BnYkBkUznwWVrg6b9amhJb8zfpuDfbgLY9m4ZZOO+66SZP/s5
EYDa6AKn6mA2iNF4yBDhXJxVmJiNYfplule8V3vFtLCdcsxso1gp8tc6FGXWj+CF
hb9h6yoZyxAjpn+LjuxBUYmTgXiL3qOE1gixHBzMt3gyZwlGcKVWSeI3eDmCZ+K3
Ez7Oqn27YPK1j/ZGDldwUpvQcHztrfabtKjqKTdbIViKOT37458/z6K1yLTio/fP
YoXhpR7ShuX/zCQmqvfOCXxilmmPF1kBj4CNb0pdoMEwMPXtV7zfPR9ZXfhw1pPS
8DfpPq6iaNLlFGXmSH0j2ORkDFc002lHxBAMIksPGcUP3L+bFpoOtB/QQJuHjJXo
qoEuYOWLwksuXofAibH+oLY52cp7cCjwWmsjNIA0F9f/KdZUaWrNHbjeu7ijdawH
70GuqPjI2KKhjguwMkr8eKtF0bQAnUqZmKVeVZESDCBTQqEjcbW6THlNEtTKax10
Xinm8Qysd5PWR/8UPq+bTrVubceOu/hLqnZVGmN8kv9VHGOPOuI=
=Iruv
-----END PGP SIGNATURE-----

--Apple-Mail=_CFD9DCE0-39DB-4B7C-83B6-1A80F1DA3B31--

--===============4765799903348919190==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
lustre-devel mailing list
[email protected]
http://lists.lustre.org/listinfo.cgi/lustre-devel-lustre.org

--===============4765799903348919190==--