Change GVFS name #72
Comments
|
Nice! 🎉 that's very appreciated! don't forget there is some scripts there to help you to rename to whatever you want: #51 🍻 Good luck for the deployment with a so-deeply established component of your development environment 😏 it would have been easier before 😉 😘 |
|
sparse versioning file system spvfs |
|
sparse virtual repository system - svrs |
|
ProjSC - Projected Source Control |
|
@sanoursa, I really appreciate that MS has heard open source devs and has reconsidered it's decision here. I'm sort of confused on your first point though (purely for the purposes of helping you brainstorm). Could you clarify? Having read #7, it's not quite clear what the issue is and thus what you're trying to avoid (unless I missed something). Do you no longer want to have a 'g' in the name at all (referring to git) or are you saying simply that the word 'git' can't be spelled out in the name? I'm kind of thrown by the 'vendor agnostic' thing. Are you trying to say the intent is to make this name agnostic to the source control management solution being used? Or are you saying that git works on multiple OSes where this does not (and you don't want that confusion)? Or both? |
|
What about simply vfsg = virtual file system for git |
|
What about VGFS - Virtual Git File System - to keep the "FS" at the end? |
|
GNTFS = GNTFS is Not a True File System (or Git Nondescript Tree-traversal File System) |
|
Really appreciate the cooperation from Microsoft here. It is very unexpected. I'm partial to RVFS / Repository Virtual File System. Google search seems to be pretty open on that one. |
|
Sparse is a good word to include here as it evokes exactly what this does |
|
also: |
|
Not because I have any idea what's going on here, but mostly just because naming is fun...
GhostFS, VirtualFS, ProxyFS, LazyFS, and SparseFS are all taken, along with most of the good acronyms. |
This comment has been minimized.
This comment has been minimized.
|
Wondering what you would do with the executable name. I suppose Microsoft puts weight on backward compatibility, but keeping the executable name By the way, is the renaming/rebranding department kicking in? |
|
Versioned Sparse File System. vsfs. But @HollisTech's suggestion also sounds great. |
|
How about "greifs" as in "git revisioned ellaborate impecable file system"? I admit the abbreviation is much nicer than the whole thing spelled out. |
|
Just call it GitFS. It doesn't have to explicitly say Virtual. That'll be mentioned in the docs. |
|
How about just TSFS? |
|
I suggest: MDDKASALFS |
|
I second TSVS. Your VSTS TFS team might like that too. :-) Even uses all the same characters. |
|
EntreFS For: Enterprise Repository File System. Also |
|
Asynchronous Immediate Repository(AIR) |
|
Filey McFileface |
|
THVFS - Team Hub Virtual File System |
|
vfs4g - vfs for git |
|
VVFS Versioned Virtual File System |
|
ShaVFS |
|
How about Dolly VFS, dolly as the executable name. First Dolly was a sheep, who was a clone, not a real sheep. Secondly, a movers Dolly lets you move large objects around easily, that would be too large to move around without help. That's kind of what this thing does. Ergo, Dolly. |
|
vfs4g - vfs for git |
|
I’m personally in favour of Or you could just call it MGVFS (Microsoft Git Virtual File System), or just MGFS (Microsoft Git File System) if you want just 4 letters. MSGVFS or (In reply to @ttaylorr from #72 (comment))
I personally don’t think that will be much of an issue, as typos are much easier to spot at the beginning or end of a word than the middle, due to how the brain processes text. |
|
@sam0x17 What you are describing is very similar to the design that has lead to privilege escalation vulnerabilities from privileged D-Bus services. Even if the IPC method is a socket or named pipe where write access is restricted to members of a specific group, for those members it is access to a message parser running in a privileged state that has been less vetted than sudo. A service also has more overhead in an idle state than a sudo call which has exited on completion. @sanoursa The mainstream Linux kernel already has a solution to avoid FUSE overhead for already hydrated files. If VFS For Git uses OverlayFS with the block storage filesystem as the upper and FUSE as the lower, then both hydrated files and whiteouts (locally deleted files) will be at native file system performance. From a functional standpoint, it seems like ProjFS is reimplementing functionality the Linux community already has had. While it may still make sense to use ProjFS for porting to WSL, I think it make less sense when porting to a real Linux kernel. As far as endpoint renaming in the protocol, I think there should be a migration path specified in the protocol description. I would recommend specifying an end date for the legacy protocol name. Before that date, the server should continue to support both and the client should fallback to the old name when the new endpoint name fails. After the end date, neither the server or client should expect the legacy endpoint name to still be provided/used. |
|
@chilinux you are right, for example someone could create a repo containing an alternate version of /ets/shadow and mount it to /etc. If it is strict about only mounting within a predefined area, and the daemon refuses to overwrite files every when cloning, I would think this could be avoided, but you are right to be cautious. FUSE is definitely the way to go with this though. A year ago I implemented a cloud-based file system using FUSE where the files are stored in encrypted blocks remotely in s3/cloud storage, and the metadata for the entire file system is stored in memory when a connection is established, and it worked beautifully and actually exceeded native performance for directory traversal etc once a connection is established (because all file system metadata is stored in memory). My system would only download file contents in response to a read/write request, and would only download in 20 MB blocks so if you modify a 700 MB file you don't need to use 700 MB of up and down bandwidth. But yeah, FUSE is perfect for this sort of thing and I really see it being easier if anything than it would be to implement this in windows. |
|
@chilinux overlayfs is copy on write, while VFS for Git does copy on read. Intuitively, the performance hit would be astronomical in a typical build and rebuild situation where most files are only read but not written. Furthermore, VFS for Git hydrates partial files (sparse files with a reparse point) which only contain metadata. Would you be able to do this with a FUSE+overlayfs scheme? Linux does support sparse files, but I don't see how that would necessarily fit in the picture without custom kernel code. @sam0x17 what kind of read workloads are you working with? For example, the information in this paper suggests that even a highly optimized Fuse implementation would have issues with large random read loads on small files (ie builds). |
|
@nlieb I tried to optimize it for a very varied load, so supporting millions of tiny files (e.g. git repositories) and large 100 GB movie files, and random reads and writes to those. Performance was acceptable across the board and better than anything currently available for cloud-based file systems, but I had 2-3 bugs I could never eliminate that I'm hoping to fix by using rust or crystal instead of node.js. |
|
as it turns out, most conventional file systems do not optimize random size-changing writes to large files and often have to re-write the entire file. |
|
@nlieb Thank you for pointing out that I wasn't completely clear in my last post. You are correct that OverlayFS only directly provides a COW implementation. With what I am suggesting upper FS from the Overlay would not be providing the Copy on Read or presenting the metadata only stubs of unhydrated files. Instead, that would still have to fall back through the OverlayFS lower FS which goes to FUSE to provides those features. However, reading the ProjFS.Mac source-available code (the code is not completely open source licensed, more on that later), it appears that ProjFS also falls back to a FUSE like behavior for copy on read and stub metadata. In terms of the FAST '17 research paper, it doesn't really apply to the situation of unhydrated or stub files which still need to be read from Git. The paper is comparing a locally stored ext4 with a stackfs FUSE shim to the locally stored ext4. It does clearly show for a good reason to avoid FUSE for already hydrated files which is what OverlayFS can provide. But for file stubs which haven't been hydrated, accessing the file locally is not an option yet as it isn't stored locally yet. The paper does not provide any comparison between something like a pure in-kernel webdav filesystem client and a FUSE one. Even if it did, ProjFS doesn't provide a pure in-kernel HTTP client, it instead falls back to a FUSE-like method for hydrating files when a stub entry is being accessed. So, while it is an interesting paper and I enjoyed reading it, the results don't really speak to advantages ProjFS would have over the existing OverlayFS and FUSE. On the other hand, if ProjFS was port to the Linux kernel, I think it would be unlikely to be accepted into the mainstream kernel code. If you read the archives of the kernel developer's mailing list, specialized code which duplicates existing generalized code tends to be rejected for inclusion. Even if it was accepted, it would be a while before it would appear standard in popular Linux distributions. In the meantime, the module would have to be compiled for each distribution which the project wants to make easy for users to install on or it would have to support something like DKMS (which I personally consider messy). As a side note, VnodeUtilities.cpp from ProjFS.Mac which is included in this repo is licensed as "All Rights Reserved." This is not consistent with the claim the project is open source and may also put the repo into violation with Github Terms of Service section D clause 5 as that license doesn't allow copying of the file such as forking the repo. Hopefully this specific issue can be resolved sooner instead of later (and bypass matthewpersico's law of Big Microsoft). |
|
@chilinux agreed, my read on this is that the only viable path forward on linux is to use FUSE as a basis. On that note, I don't know much about the linux kernel itself, but would all of this be possible with a kernel module, like what virtualbox uses? Not my area so I wouldn't know. |
|
@chilinux The HTTP hydration portion is in userspace--though that does not mean it should be implemented with FUSE. It could be implemented with some kind of communication over a /dev device to the VFSforGit daemon.
In my opinion, the viability of this project hinges on those features being present in-kernel. In particular, copy-on-read to the upper cache layer is crucial. If you use FUSE to access previously copied-on-read data, you are back to the performance issues mentioned by FAST '17. Most files in a build are only read, not written. If you skim through this video presentation on the ProjFS architecture around 17:35 (please excuse the loud intro) you will see that the full ProjFS implementation on Windows performs copy-on-read to the upper layer. Another issue that I could see is that overlayfs expects the lower layer to be immutable (see this documentation) though I'm not sure what the full implications of that would be. edit: This is veering pretty off-topic, maybe this discussion deserves its own thread |
|
@chilinux thanks for pointing out the copyright notice, that definitely should not be there. I think it was mistakenly added by someone's default editor settings, and I have filed #149 to remove it. In general, feel free to file issues for problems that you find in the code. @nlieb I agree that the FUSE discussion is off topic here. #126 would be a better place for this discussion. That said, thanks to everyone for all the ideas around how to implement this on Linux. I will restate that I know very little about our available options there, so very open to ideas and suggestions. @nlieb is spot on though, we have a primary constraint that we require near native file system speeds for reads (after initial hydration), or build performance will be unacceptable. There's also a secondary constraint, super nice to have though not required if there are strong reasons to abandon it, to preserve the same driver model on all operating systems so that our user mode code can be the same everywhere. Beyond those two, I think the playing field is currently wide open for our Linux designs. |
|
@sanoursa Is it possible to get any sort of status update on the progress being made? General consensus on the new name was stated as being reached on July 13 which was 30 days ago. Of the resulting issues opened, none have been closed or have comments indicating any partial progress. I am sure there is progress taking place behind the scenes but based on previous statements made, I was expecting the progress to be more transparent/open. I was expecting at least Issue #129 would show some partial results by this point such as the name change being reflected in the content of the web page even if the URL hasn't been updated yet. |
I have not had time to move this, nor will I until our next sprint. Appreciate your patience. |
|
Giin. (git it if needed)... Then create a desktop client called Tonic. |
|
JTBYNFS • Just The Bits You Need File System Too wordy? |
|
As much as I like Giin, the poll closed two months ago. |
|
Is it worth locking the discussion on this issue? As noted, the decision
making process is over, so further discussion here is not necessary.
|
|
@ttaylorr I believe sanoursa already addressed this question back on July 10th with: While you are correct the decision making process is over since July 13th, now two months ago, the issue is not all resolved. The tasks that have been resolved is:
Tasks (non-long term) that are still open and have no status update to indicate any progress yet:
So of the non-long term tasks, after two months this is still only 20% of the way from all resolved. At the current rate of progress of 10% per month, this should be ready to lock/close around May 2019. What leaving it open for now does is show that this iteration of Microsoft being serious about interacting with the community is serious. This isn't the first time Microsoft has tried to indicate they want to have an open two way dialog with the community. While previous attempts such as Codeplex and TechNet Port25 was well intended, the follow through and results tended to be poor. Yet another locking out further community discussion after promising it wouldn't until fully resolved could have a chilling effect on community involvement. Or worse, locking further discussion here will push the discussion onto other forums were the results of the discussion is more likely to be even more critical of Microsoft's claim to be open to the community. If the current downside to leaving the issue open is that some people continue to suggest names which never get used, does that "negative" really outway the positives of encouraging community involvement? Is there something offensive about the most recent suggestions that I am missing? |
|
The only negative part I can see is newcomers coming in and getting disappointed. Better than chilling the conversation, but not the perfect community management strategy either. Proposed compromise: Append "UPDATE: The name chosen is VFS For Git, further suggestions won't be used, thanks for your participation" to the OP. |
|
Or prepend it, which is what I do. |
|
Whatever happened to point#1- no git in name? Spvfs (spoofs, the pronunciation also indicated what it does) was a mused opportunity. |
|
Shouldn't the repo be called Also, this is how it's written on the website: https://vfsforgit.org/ |
|
Or |
Yup, that's what I thought. At least then can change it without breaking any links. |
|
It has been one year since the creation of Issue #72. Here is a summary of how I view the current situation. Timeline of related events for Issue #72: Dec 2001 Microsoft demands Lindows make a name change despite it not running on any Microsoft's products Sep 2007 Repository for GVFS for GNOME desktop created Mar 2008 Wikipedia page on GVFS for GNOME desktop created, soon after it can easily be found via searches for "GVFS" performed via Bing or Google Feb 2017 Microsoft GVFS released on Github Feb 2017 Community kindly points out the GVFS name is already taken (Issue #7). Microsoft response is that "they do not run on the same operating systems, so there is no risk of confusion." This response violates the precedence previously set by Microsoft that similar names that don't run on the same OS can cause confusion. Jun 2018 Microsoft acquires GitHub. Microsoft employees points to MS-GVFS project as proof that Microsoft is now taking the Open Source community and fears about the new ownership are not warranted. Jun 2018 Microsoft GVFS Project finally opens Issue #72 to change the name Jun 2019 First anniversary of Issue #72 (also over 2 years after Issue #7 was opened) but the issue is still not full addressed Issue #72 Tasks already resolved:
Issue #72 Tasks not resolved:
As far as the last task having a question mark, I believe the answer should not only be yes but renaming the endpoint should also be treated as a chance to revise the protocol endpoint as well. The current protocol is poorly described with a document that is not self-contained. Instead of giving a complete protocol description and examples, it provides unhelpful information as "the request/response look similar to [external document]." Can you imagine the chilling effect it would have on adoption if RFC 2068 simply said the request/response look similar to the gopher protocol? It would be nice if the new endpoint protocol was based on git's smart protocol instead of the existing MS-GVFS protocol v1 based around git's dumb protocol. A well documented new endpoint based on the git smart protocol with an open source server reference implementation would help greatly with the following:
I believe new release of WSL2 may be helpful in attracting more community members to this project. There is the potential for WSL2 to make it easier to work on porting this project to Linux. Developers wanting to run VFS for Git side by side between Windows and a port to WSL will finally have open source access to the Linux VFS layer instead of just a closed WSL1 MS runtime environment. However, in terms of tasks in Issue #72 the community can be of limited help. Every pending Issue #72 related task either need to be directly done by Microsoft or needs additional guidance from Microsoft that hasn't been stated in the github Issue comments yet. For example, the community can't update the Git at Scale articles, by Microsoft policy that must be done by Microsoft. Also, the community can't meaningfully contribute to the new CLI design until Microsoft decides on what that design should be. WIthout a designation on the design, it is unlikely any PR which attempts to decide the design independent of Microsoft will ever be accepted into the mainstream code. Most importantly, Issue #72 shouldn't be left in a state that gives the appearance Microsoft is still continuing the empty posturing of the TechNet Port 25 blog and CodePlex days. Taking over 2 years from the time the community makes a simple request to still not having honored the request is not the right way to demonstrate how Microsoft is taking the concerns of the community seriously. |
I don't think so. Lindows was a competing product to Windows, both were operating systems that ran on x86 computers, so confusion seems likely. VFS for Git isn't related to GVFS except by name, one is for Gnome, a desktop environment, and one is for Git, a version control system. |
Real GVFS is by the same group as the GNOME desktop environment but does not need to be for GNOME. The desktop environment does not need to be running to use GVFS. Saying GNOME GVFS is for the desktop environment is kind of like saying VFS for Git is for DirectX. The both come from the same group of authors and use some of the same libraries but one can be used without the other. The distinction is important with situations like WSL1. Under WSL1, developers have been locked out of adding and modifying file system code. The way around accomplishing a port of VFS for Git to WSL1 would be to use a library shim for file system functions. It turns out real GNOME GVFS happens to be such a shim. But getting other developers interested in a project of porting "GVFS to use GVFS" is needlessly difficult and doesn't get any traction because the name IS confusing. I have been told by Microsoft employees that Microsoft Azure is heavily invested in supporting Linux and one of the things they would "like" is community involvement in porting VFS for Git to Linux. But the name confusion goes against the claim Microsoft really wants the community to be involved. It is an extra hurtle in discussion of the port. Regardless of why Issue #7 had to be ignored for some long, once Issue #72 was open, there should have been commitment to making progress on completing. Several of the issues have shown no progress and also more importantly no publicly stated updates. I didn't fully expect all of the issues would be taken care of in under a year, but I did expect some sort of ETA for each issue by now. This feel again like a posturing promotional move just like the "open source" release of Singularity. While at least VFS for Git is under a real open source license, that is still not the same as promoting community involvement with the project or being community friendly. |
|
My 2 Cents: #130 (comment) There's a reason why Git tools and extensions are called Git <Tool/Ext.> because it uses or extends Git! You can always call a common product/technology a different name, but vendor (Git) specific tools and extensions should always be 🎤💧 |
and others
We’ve heard the feedback, so lets use this issue to come up with a new name for this project. As we all know, folks from Microsoft don’t have a rich tradition of picking super awesome names for things. I'm no exception to that pattern, so I was thinking we could all put some sensible suggestions into this issue. I’ll then compile a short list and then we’ll all get to vote on the new name.
Some guidelines:
I'll put my thinking cap on and start putting some stuff in here, but please add your ideas. Making the name change won't be as simple as doing
s/gvfs/newname/gso I'll need to do some stuff once we pick a name, but I'm excited to try to come up with something cool.The text was updated successfully, but these errors were encountered: