<html>
<head>
<meta content="text/html; charset=windows-1252"
http-equiv="Content-Type">
</head>
<body text="#000000" bgcolor="#FFFFFF">
Comments inline.<br>
<br>
<div class="moz-cite-prefix">On 18/08/15 09:54, Niels de Vos wrote:<br>
</div>
<blockquote
cite="mid:20150818042417.GL3514@ndevos-x240.usersys.redhat.com"
type="cite">
<pre wrap="">On Mon, Aug 17, 2015 at 06:20:50PM +0530, Anoop C S wrote:
</pre>
<blockquote type="cite">
<pre wrap="">Hi all,
As we move forward, in order to fix the limitations with current trash
translator we are planning to replace the existing criteria for trashed
files inside trash directory with a general flat hierarchy as described
in the following sections. Please have your thoughts on following
design considerations.
Current implementation
======================
* Trash translator resides on glusterfs server stack just above posix.
* Trash directory (.trashcan) is created during volume start and is
visible under root of the volume.
* Each trashed file is moved (renamed) to trash directory with an
appended time stamp in the file name.
* Exact directory hierarchy (w.r.t the root of volume) is maintained
inside trash directory whenever a file is deleted/truncated from a
directory
Outstanding issues
==================
* Since renaming occurs at the server side, client-side is unaware of
trash doing rename or create operations.
* As a result files/directories may not be visible from mount point.
</pre>
</blockquote>
<pre wrap="">This might be something upcall could help with. If the trash xlator is
placed above upcall, any clients interested in the .trashcan directory
(or subdirs) could get an in/revalidation request.
</pre>
<blockquote type="cite">
<pre wrap="">* Files/Directories created from from trash translator will not have
gfid associated with it until lookup is performed.
</pre>
</blockquote>
<pre wrap="">When a client receives an invalidation of the parent directory (from
upcall), a LOOKUP will follow on the next request.
</pre>
</blockquote>
<br>
If I understand it correctly , solution become more complex if
integrate both translator and upcall together.<br>
1.) Upcall notification can be send to a client only if it has
accessed .trashcan<br>
2.) There should be translator at client side to initiate lookup
after receiving upcall notification<br>
3.) Performance hit. Say file `foo`is present in a/b/c/. We need to
create path a/b/c/ inside trash directory.<br>
So ideally trash xlator will first create directory 'a' , then send
upcall notification to all of the client and then clients will
initiate lookup on 'a',<br>
perform gfid healing on that directory. After that it will create
`b` and repeat the same procedure. <br>
<blockquote
cite="mid:20150818042417.GL3514@ndevos-x240.usersys.redhat.com"
type="cite">
<pre wrap="">
</pre>
<blockquote type="cite">
<pre wrap="">Proposed Flat hierarchy
=======================
</pre>
</blockquote>
<pre wrap="">I'm missing a bit of info here, what limitations need to be addressed?
</pre>
</blockquote>
<br>
all above mentioned outstanding issues can be addressed by the flat
hierarchy.<br>
<blockquote
cite="mid:20150818042417.GL3514@ndevos-x240.usersys.redhat.com"
type="cite">
<pre wrap="">
</pre>
<blockquote type="cite">
<pre wrap="">* Instead of creating the whole directory under trash, we will rename
the file and place it directly under trash directory (of course with
appended time stamp).
* Directory hierarchy can be stored via either of the following two
approaches:
(a) File name will contain the whole path with time stamp
appended
(b) Store whole hierarchy as an xattr
</pre>
</blockquote>
<pre wrap="">If this is needed, definitely go with (b). Filenames have a limit, and
the full path (directories + filename + timestamp) could surely hit
that.
</pre>
</blockquote>
<br>
Thanks for the suggestion.<br>
<br>
<blockquote
cite="mid:20150818042417.GL3514@ndevos-x240.usersys.redhat.com"
type="cite">
<pre wrap="">
</pre>
<blockquote type="cite">
<pre wrap="">Other enhancements
==================
</pre>
</blockquote>
<pre wrap="">Have these been filed as bugs/RFEs? If not, please do so and include a
good description of the work that is needed. Maybe others in the Gluster
community are interested in providing patches, and details on what to do
is very helpful.
</pre>
</blockquote>
<br>
Sure. We will file different RFE's as soon as possible and sent it
in different mail.<br>
<br>
<blockquote
cite="mid:20150818042417.GL3514@ndevos-x240.usersys.redhat.com"
type="cite">
<pre wrap="">Thanks,
Niels
</pre>
<blockquote type="cite">
<pre wrap="">* Create the trash directory only
when trash xlator is enabled.
* Operations such as unlink, rename etc
will be prevented on trash
directory only when trash xlator is
enabled.
* A new trash helper translator on client side(loaded only when
trash
is enabled) to resolve split brain issues with truncation of
files.
* Restore files from trash with the help of an explicit setfattr
call.
Thanks & Regards,
-Anoop C S
-Jiffin Tony Thottan
_______________________________________________
Gluster-devel mailing list
<a class="moz-txt-link-abbreviated" href="mailto:Gluster-devel@gluster.org">Gluster-devel@gluster.org</a>
<a class="moz-txt-link-freetext" href="http://www.gluster.org/mailman/listinfo/gluster-devel">http://www.gluster.org/mailman/listinfo/gluster-devel</a>
</pre>
<br>
</blockquote>
</blockquote>
<br>
--<br>
Jiffin<br>
<blockquote
cite="mid:20150818042417.GL3514@ndevos-x240.usersys.redhat.com"
type="cite">
<blockquote type="cite">
<fieldset class="mimeAttachmentHeader"></fieldset>
<br>
<pre wrap="">_______________________________________________
Gluster-devel mailing list
<a class="moz-txt-link-abbreviated" href="mailto:Gluster-devel@gluster.org">Gluster-devel@gluster.org</a>
<a class="moz-txt-link-freetext" href="http://www.gluster.org/mailman/listinfo/gluster-devel">http://www.gluster.org/mailman/listinfo/gluster-devel</a>
</pre>
</blockquote>
</blockquote>
<br>
</body>
</html>