linux-kernel - Re: [PATCH 12/35] Unionfs: Documentation

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date:	Tue, 5 Dec 2006 21:52:08 +0100 (MET)
From:	Jan Engelhardt <jengelh@...ux01.gwdg.de>
To:	"Josef 'Jeff' Sipek" <jsipek@...sunysb.edu>
cc:	linux-kernel@...r.kernel.org, torvalds@...l.org, akpm@...l.org,
	hch@...radead.org, viro@....linux.org.uk,
	linux-fsdevel@...r.kernel.org, mhalcrow@...ibm.com
Subject: Re: [PATCH 12/35] Unionfs: Documentation


>+++ b/Documentation/filesystems/unionfs/00-INDEX
>@@ -0,0 +1,8 @@
>+00-INDEX
>+	- this file.
>+concepts.txt
>+	- A brief introduction of concepts
>+rename.txt
>+	- Information regarding rename operations
>+usage.txt
>+	- Usage & known limitations

Try "and", & is so... 'lazy'.


>+Since 'foo' is stored on a read-only branch, it cannot be removed. A whiteout
>+is used to remove the name 'foo' from the unified namespace. Again, since
>+branch 1 is read-only, the whiteout cannot be created there. So, we try on a
>+higher priority (lower numerically) branch. And there we create the whiteout.

higher priority (numerically lower) branch and create the whiteout there.
(Starting a sentence with 'and' is like telling fairytales^W stories.)

>+solution is to take the instance from the highest priority (lowest numerical
>+value) and "hide" the others.

(numerically lowest value)

>+When a change is made to the contents of a file's data or meta-data, they
>+have to be stored somewhere. The best way is to create a copy of the
>+original file on a branch that is writable, and then redirect the write
>+though to this copy. The copy must be made on a higher priority branch so
>+that lookup & readdir return this newer "version" of the file rather than
>+the original (see duplicate elimination).

s/&/and/g;

>+Modifying a Unionfs branch directly, while the union is mounted is currently
>+unsupported.

Either:
  Modifying a Unionfs branch directly while the union
  is mounted is currently unsupported.
Or:
  Modifying a Unionfs branch directly, while the union
  is mounted, is currently unsupported.

>  Any such change can cause Unionfs to oops, however it could even
>+RESULT IN DATA LOSS.

Or stay silent (-> silent data corruption / loss)

>+Unionfs shouldn't use lookup_one_len on the underlying fs as it confuses

For written text, non-shortened forms (should not) are preferred. At least
that's (<- that's texified speech not documentation) what we were told back in
scool :p

>+NFS. Currently, unionfs_lookup passes lookup intents to the lower

  should not use lookup_one_len() [...] Currently, unionfs_lookup()

most doc add () to clarify it is a function.

>+filesystem, this eliminates part of the problem. The remaining calls to
>+lookup_one_len may need to be changed to pass an intent.

~

	-`J'
-- 
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/