So I looked at the code - it seems you build a full extent of the blocks
in the file, filling holes as you go along. I initally did that as well,
but that is to slow to be usable in real life.
You also don't support sparse files, falling back to normal fs
read/write paths. Supporting sparse
Hello.
Indan Zupancic wrote:
It seems to me that the alternatives you are proposing include
modification of userland applications. But my assumption is
that Don't require modification of userland applications.
If you want a secure system it isn't that unreasonable to expect
Hi,
On Fri, January 11, 2008 09:46, Tetsuo Handa wrote:
It depends.
Some users have to continue using brain dead legacy applications
without modification because ...
the application's source code is not available.
Source isn't needed, as long as the vendor has it.
the distributor no
On Fri, Jan 11, 2008 at 11:05:07PM +0900, Tetsuo Handa wrote:
Not only mknod() but also rename()/unlink()/link()/mount(bind) etc. that may
cause filename/attribute mismatching.
How can the daemon know whether the request is trying to manipulate nodes
in /dev directory or not?
If mount
On Fri, 11 Jan 2008 10:01:18 +1100
Neil Brown [EMAIL PROTECTED] wrote:
On Thursday January 10, [EMAIL PROTECTED] wrote:
On Thu, Jan 10 2008, Chris Mason wrote:
On Thu, 10 Jan 2008 09:31:31 +0100
Jens Axboe [EMAIL PROTECTED] wrote:
On Wed, Jan 09 2008, Alasdair G Kergon wrote:
Al Boldi [EMAIL PROTECTED] wrote:
Even after a black-out shutdown, the corruption is pretty minimal, using
ext3fs at least. So let's take advantage of this fact and do an optimistic
fsck, to assure integrity per-dir, and assume no external corruption. Then
we release this checked dir to the
Igor's overview of the patch series is:
http://marc.info/?l=linux-cifs-clientr=1b=200712w=2
Although most of the CIFS DFS support is merged, there are three
remaining patches to finish review before merge. One, for completing
CIFSGetDFSReferral, is probably less interesting to fsdevel:
Hello.
Indan Zupancic wrote:
That only the tiny daemon can modify /dev/ is done with MAC rules,
the ones that should be the default for all applications except udev by
default already. For teh kernel nothing changes.
OK. You assume use of MAC with enough fine grained access control.
On Fri, Jan 11 2008, Daniel Phillips wrote:
Hi Jens,
This looks really useful.
On Wednesday 09 January 2008 00:52, Jens Axboe wrote:
Disadvantages:
- The file block mappings must not change while loop is using the
file. This means that we have to ensure exclusive access to the file
Hi Jens,
This looks really useful.
On Wednesday 09 January 2008 00:52, Jens Axboe wrote:
Disadvantages:
- The file block mappings must not change while loop is using the
file. This means that we have to ensure exclusive access to the file
and this is the bit that is currently missing in the
10 matches
Mail list logo
