Re: [ceph-users] Status of SAMBA VFS
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On Fri, 6 Feb 2015, Gregory Farnum wrote: On Fri, Feb 6, 2015 at 7:11 AM, Dennis Kramer (DT) wrote: On Fri, 6 Feb 2015, Gregory Farnum wrote: On Fri, Feb 6, 2015 at 6:39 AM, Dennis Kramer (DT) wrote: I've used the upstream module for our production cephfs cluster, but i've noticed a bug where timestamps aren't being updated correctly. Modified files are being reset to the beginning of Unix time. It looks like this bug only manifest itself in applications like MS Office where extra metadata is added to files. If I for example modify a text file in notepad everything is working fine, but when I modify a docx (or .xls for that matter), the timestamp is getting a reset to 1-1-1970. You can imagine that this could be a real dealbreaker for production use (think of backups/rsyncs based on mtimes which will render useless). Further more the return values for free/total disk space is also not working correctly when you mount a share in Windows. My 340TB cluster had 7.3EB storage available in Windows ;) This could be fixed with a workaround by using a custom "dfree command =" script in the smb.conf, but VFS will override this and thus this script will not work (unless you remove the lines of codes for these disk operations in vfs_ceph.c). My experience with the VFS module is pretty awesome nonetheless. I really noticed an improvement in throughput when using this module instead of an re-export with the kernel client. So I hope the VFS module will be maintained actively again any time soon. Can you file bugs for these? The timestamp one isn't anything I've heard of before. http://tracker.ceph.com/issues/10834 The weird free space on Windows actually does sound familiar; I think it has to do with either Windows or the Samba/Windows interface not handling our odd block sizes properly... This one has been fixed. http://tracker.ceph.com/issues/10835 -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.12 (GNU/Linux) iEYEARECAAYFAlTd3gsACgkQiJDTKUBxIRseAQCeNFsD4jEQKqsWvGVWPph1m6+S o+QAoNDy9zrcxdYNYBM+czdMpV9DV6o1 =U/hx -END PGP SIGNATURE- ___ ceph-users mailing list ceph-users@lists.ceph.com http://lists.ceph.com/listinfo.cgi/ceph-users-ceph.com
Re: [ceph-users] Status of SAMBA VFS
On Fri, Feb 6, 2015 at 7:11 AM, Dennis Kramer (DT) wrote: > > On Fri, 6 Feb 2015, Gregory Farnum wrote: > >> On Fri, Feb 6, 2015 at 6:39 AM, Dennis Kramer (DT) >> wrote: >>> >>> I've used the upstream module for our production cephfs cluster, but i've >>> noticed a bug where timestamps aren't being updated correctly. Modified >>> files are being reset to the beginning of Unix time. >>> >>> It looks like this bug only manifest itself in applications like MS >>> Office >>> where extra metadata is added to files. If I for example modify a text >>> file >>> in notepad everything is working fine, but when I modify a docx (or .xls >>> for >>> that matter), the timestamp is getting a reset to 1-1-1970. >>> You can imagine that this could be a real dealbreaker for production use >>> (think of backups/rsyncs based on mtimes which will render useless). >>> >>> Further more the return values for free/total disk space is also not >>> working >>> correctly when you mount a share in Windows. My 340TB cluster had 7.3EB >>> storage available in Windows ;) This could be fixed with a workaround by >>> using a custom "dfree command =" script in the smb.conf, but VFS will >>> override this and thus this script will not work (unless you remove the >>> lines of codes for these disk operations in vfs_ceph.c). >>> >>> My experience with the VFS module is pretty awesome nonetheless. I really >>> noticed an improvement in throughput when using this module instead of an >>> re-export with the kernel client. So I hope the VFS module will be >>> maintained actively again any time soon. >> >> >> Can you file bugs for these? The timestamp one isn't anything I've >> heard of before. >> The weird free space on Windows actually does sound familiar; I think >> it has to do with either Windows or the Samba/Windows interface not >> handling our odd block sizes properly... >> -Greg >> > > Sure, just point me in the right direction for these bug reports. > > It's true BTW, IIRC Windows defaults to 1024k block size for calculating the > free/total space, but this could be managed by the vfs module. Windows only > expects two mandatory values, available- and total space in bytes and > optionally the block size as a third value. You can just report them at http://tracker.ceph.com/projects/cephfs. -Greg ___ ceph-users mailing list ceph-users@lists.ceph.com http://lists.ceph.com/listinfo.cgi/ceph-users-ceph.com
Re: [ceph-users] Status of SAMBA VFS
On Fri, 6 Feb 2015, Gregory Farnum wrote: On Fri, Feb 6, 2015 at 6:39 AM, Dennis Kramer (DT) wrote: I've used the upstream module for our production cephfs cluster, but i've noticed a bug where timestamps aren't being updated correctly. Modified files are being reset to the beginning of Unix time. It looks like this bug only manifest itself in applications like MS Office where extra metadata is added to files. If I for example modify a text file in notepad everything is working fine, but when I modify a docx (or .xls for that matter), the timestamp is getting a reset to 1-1-1970. You can imagine that this could be a real dealbreaker for production use (think of backups/rsyncs based on mtimes which will render useless). Further more the return values for free/total disk space is also not working correctly when you mount a share in Windows. My 340TB cluster had 7.3EB storage available in Windows ;) This could be fixed with a workaround by using a custom "dfree command =" script in the smb.conf, but VFS will override this and thus this script will not work (unless you remove the lines of codes for these disk operations in vfs_ceph.c). My experience with the VFS module is pretty awesome nonetheless. I really noticed an improvement in throughput when using this module instead of an re-export with the kernel client. So I hope the VFS module will be maintained actively again any time soon. Can you file bugs for these? The timestamp one isn't anything I've heard of before. The weird free space on Windows actually does sound familiar; I think it has to do with either Windows or the Samba/Windows interface not handling our odd block sizes properly... -Greg Sure, just point me in the right direction for these bug reports. It's true BTW, IIRC Windows defaults to 1024k block size for calculating the free/total space, but this could be managed by the vfs module. Windows only expects two mandatory values, available- and total space in bytes and optionally the block size as a third value. ___ ceph-users mailing list ceph-users@lists.ceph.com http://lists.ceph.com/listinfo.cgi/ceph-users-ceph.com
Re: [ceph-users] Status of SAMBA VFS
On Fri, Feb 6, 2015 at 6:39 AM, Dennis Kramer (DT) wrote: > I've used the upstream module for our production cephfs cluster, but i've > noticed a bug where timestamps aren't being updated correctly. Modified > files are being reset to the beginning of Unix time. > > It looks like this bug only manifest itself in applications like MS Office > where extra metadata is added to files. If I for example modify a text file > in notepad everything is working fine, but when I modify a docx (or .xls for > that matter), the timestamp is getting a reset to 1-1-1970. > You can imagine that this could be a real dealbreaker for production use > (think of backups/rsyncs based on mtimes which will render useless). > > Further more the return values for free/total disk space is also not working > correctly when you mount a share in Windows. My 340TB cluster had 7.3EB > storage available in Windows ;) This could be fixed with a workaround by > using a custom "dfree command =" script in the smb.conf, but VFS will > override this and thus this script will not work (unless you remove the > lines of codes for these disk operations in vfs_ceph.c). > > My experience with the VFS module is pretty awesome nonetheless. I really > noticed an improvement in throughput when using this module instead of an > re-export with the kernel client. So I hope the VFS module will be > maintained actively again any time soon. Can you file bugs for these? The timestamp one isn't anything I've heard of before. The weird free space on Windows actually does sound familiar; I think it has to do with either Windows or the Samba/Windows interface not handling our odd block sizes properly... -Greg ___ ceph-users mailing list ceph-users@lists.ceph.com http://lists.ceph.com/listinfo.cgi/ceph-users-ceph.com
Re: [ceph-users] Status of SAMBA VFS
I've used the upstream module for our production cephfs cluster, but i've noticed a bug where timestamps aren't being updated correctly. Modified files are being reset to the beginning of Unix time. It looks like this bug only manifest itself in applications like MS Office where extra metadata is added to files. If I for example modify a text file in notepad everything is working fine, but when I modify a docx (or .xls for that matter), the timestamp is getting a reset to 1-1-1970. You can imagine that this could be a real dealbreaker for production use (think of backups/rsyncs based on mtimes which will render useless). Further more the return values for free/total disk space is also not working correctly when you mount a share in Windows. My 340TB cluster had 7.3EB storage available in Windows ;) This could be fixed with a workaround by using a custom "dfree command =" script in the smb.conf, but VFS will override this and thus this script will not work (unless you remove the lines of codes for these disk operations in vfs_ceph.c). My experience with the VFS module is pretty awesome nonetheless. I really noticed an improvement in throughput when using this module instead of an re-export with the kernel client. So I hope the VFS module will be maintained actively again any time soon. On Fri, 6 Feb 2015, Sage Weil wrote: On Fri, 6 Feb 2015, Dennis Kramer (DT) wrote: Hi, Is the Samba VFS module for CephFS actively maintained at this moment? I haven't seen much updates in the ceph/samba git repo. You should really ignore the ceph/samba fork; it isn't used. The Ceph VFS driver is upstream in Samba and maintained there. That said, it isn't being actively developed at the moment, but I'm hoping to change that shortly! We do some basic nightly testing in the ceph lab but I'd be very interested in hearing about users' experiences. Thanks! sage ___ ceph-users mailing list ceph-users@lists.ceph.com http://lists.ceph.com/listinfo.cgi/ceph-users-ceph.com
Re: [ceph-users] Status of SAMBA VFS
On Fri, 6 Feb 2015, Dennis Kramer (DT) wrote: > Hi, > > Is the Samba VFS module for CephFS actively maintained at this moment? > I haven't seen much updates in the ceph/samba git repo. You should really ignore the ceph/samba fork; it isn't used. The Ceph VFS driver is upstream in Samba and maintained there. That said, it isn't being actively developed at the moment, but I'm hoping to change that shortly! We do some basic nightly testing in the ceph lab but I'd be very interested in hearing about users' experiences. Thanks! sage ___ ceph-users mailing list ceph-users@lists.ceph.com http://lists.ceph.com/listinfo.cgi/ceph-users-ceph.com
[ceph-users] Status of SAMBA VFS
Hi, Is the Samba VFS module for CephFS actively maintained at this moment? I haven't seen much updates in the ceph/samba git repo. With regards, ___ ceph-users mailing list ceph-users@lists.ceph.com http://lists.ceph.com/listinfo.cgi/ceph-users-ceph.com
