= BYTE_OFFSET_IN_FILE_TO_PREALLOCATE_TO;
if (!SetFileInformationByHandle(f, FileAllocationInfo, ai,
sizeof(ai))) {
// Failed.
return 1;
}
Hope this is of some use to use...
Best regards,
Anton
--
Anton Altaparmakov aia21 at cam.ac.uk (replace at with @)
Unix
] drop_cap_sys_rawio_for_fibmap.patch, is of
course, not to be applied until any remaining issues are fixed :)
Thanks,
Mike Waychison
--
Anton Altaparmakov aia21 at cam.ac.uk (replace at with @)
Unix Support, Computing Service, University of Cambridge, CB2 3QH, UK
Linux NTFS maintainer, http://www.linux
Hi Barry,
On 24 Oct 2007, at 08:39, Barry Naujok wrote:
On Tue, 23 Oct 2007 20:07:47 +1000, Anton Altaparmakov [EMAIL PROTECTED]
wrote:
I forgot to say: If you do what I did for NTFS you can also throw
away your custom dentry operations that your patch adds as the dcache
then only holds
regards,
Anton
Other TODOs:
- support for case-insensitve extended attributes
as a separate mount option.
- Other xfsprogs updates: xfs_repair, xfs_db
--
Anton Altaparmakov aia21 at cam.ac.uk (replace at with @)
Unix Support, Computing Service, University of Cambridge, CB2 3QH
loads...
Best regards,
Anton
On 23 Oct 2007, at 11:01, Anton Altaparmakov wrote:
Hi,
On 23 Oct 2007, at 08:53, Barry Naujok wrote:
Following is the initial test version of case-insensitive support
for XFS in Linux. It implements case-insensitivity utilising a
Unicode case folding table
Hi,
On 6 Oct 2007, at 07:37, Brad Boyer wrote:
On Fri, Oct 05, 2007 at 08:10:23PM +0100, Anton Altaparmakov wrote:
But the default does not matter for NTFS. At mount time, the upcase
table stored on the volume is read into memory and compared to the
default one. If they match perfectly
the existing one and export it or the existing one should go away
and the inline should be used. It seems silly to have two functions
with different names doing exactly the same thing!
Best regards,
Anton
--
Anton Altaparmakov aia21 at cam.ac.uk (replace at with @)
Unix Support
On 19 Sep 2007, at 09:09, David Rientjes wrote:
On Wed, 19 Sep 2007, Anton Altaparmakov wrote:
Index: linux-2.6/include/linux/mm.h
===
--- linux-2.6.orig/include/linux/mm.h 2007-09-17 21:46:06.0
-0700
+++ linux-2.6
On 19 Sep 2007, at 10:19, David Rientjes wrote:
On Wed, 19 Sep 2007, Anton Altaparmakov wrote:
Although it may cause a problem as highmem.h also includes mm.h so
a bit of
trickery may be needed to get it to compile...
I suspect that is_vmalloc_addr() should not be in linux/mm.h at
all
On 19 Sep 2007, at 18:29, Christoph Lameter wrote:
On Wed, 19 Sep 2007, Anton Altaparmakov wrote:
I suspect that is_vmalloc_addr() should not be in linux/mm.h at
all and should
be in linux/vmalloc.h instead and vmalloc.h should include linux/
highmem.h.
That would be more sensible than
something
about it...
Best regards,
Anton
--
Anton Altaparmakov aia21 at cam.ac.uk (replace at with @)
Unix Support, Computing Service, University of Cambridge, CB2 3QH, UK
Linux NTFS maintainer, http://www.linux-ntfs.org/
-
To unsubscribe from this list: send the line unsubscribe linux
muddy though so it is not a very enjoyable
experience falling/being thrown into it.
Nice for punting on though when the weather is nice. (-:
Best regards,
Anton
--
Anton Altaparmakov aia21 at cam.ac.uk (replace at with @)
Unix Support, Computing Service, University of Cambridge, CB2 3QH
into extents (bio sized), and the result is completely full of
dark
dark corner cases.
I do think fsblocks is a nice cleanup on its own, but Dave has a good
point that it makes sense to look for ways generalize things even
more.
-chris
--
Anton Altaparmakov aia21 at cam.ac.uk (replace
() and is avoided by ilookup5_nowait(). This
deadlock is inherent to what NTFS does so you don't need to worry
about it. (If you want I am happy to explain it but I would rather
not waste my time explaining if no-one except me cares about it...)
Best regards,
Anton
--
Anton
On 3 May 2007, at 08:49, Andreas Dilger wrote:
On May 02, 2007 20:57 +1000, David Chinner wrote:
On Wed, May 02, 2007 at 10:36:12AM +0100, Anton Altaparmakov wrote:
HSM_READ is definitely _NOT_ required because all
it means is if the file is OFFLINE, bring it ONLINE and then return
On 2 May 2007, at 09:23, Anton Altaparmakov wrote:
On 1 May 2007, at 23:30, Andreas Dilger wrote:
On May 01, 2007 14:22 +1000, David Chinner wrote:
On Mon, Apr 30, 2007 at 04:44:01PM -0600, Andreas Dilger wrote:
Hmm, I'd thought offline would migrate to EXTENT_UNKNOWN, but
I didn't
I
On 2 May 2007, at 10:15, David Chinner wrote:
On Tue, May 01, 2007 at 07:46:53PM +0100, Anton Altaparmakov wrote:
On 1 May 2007, at 15:20, David Chinner wrote:
So, either the filesystem will understand the flag or iff the
unknown flag
is in the incompat set, it will return EINVAL or else
On 2 May 2007, at 10:15, David Chinner wrote:
On Tue, May 01, 2007 at 07:46:53PM +0100, Anton Altaparmakov wrote:
And all applications will run against a multitude of
kernels. So version X of the application will run on kernel 2.4.*,
2.6.*, a.b.*, etc... For future expandability
On 2 May 2007, at 10:48, David Chinner wrote:
On Wed, May 02, 2007 at 09:23:38AM +0100, Anton Altaparmakov wrote:
On a different issue, do you think it would be worth adding an option
flags like FIEMAP_DONT_RELOCATE or something similar that would be a
compulsory flag and if set the FS
On 2 May 2007, at 11:57, David Chinner wrote:
On Wed, May 02, 2007 at 10:36:12AM +0100, Anton Altaparmakov wrote:
On 2 May 2007, at 10:15, David Chinner wrote:
On Tue, May 01, 2007 at 07:46:53PM +0100, Anton Altaparmakov wrote:
And all applications will run against a multitude of
kernels
-
issue without thinking about it first...
Best regards,
Anton
--
Anton Altaparmakov aia21 at cam.ac.uk (replace at with @)
Unix Support, Computing Service, University of Cambridge, CB2 3QH, UK
Linux NTFS maintainer, http://www.linux-ntfs.org/
-
To unsubscribe from this list: send
.
Best regards,
Anton
--
Anton Altaparmakov aia21 at cam.ac.uk (replace at with @)
Unix Support, Computing Service, University of Cambridge, CB2 3QH, UK
Linux NTFS maintainer, http://www.linux-ntfs.org/
-
To unsubscribe from this list: send the line unsubscribe linux-fsdevel in
the body
Hi Andreas,
On 13 Apr 2007, at 05:01, Andreas Dilger wrote:
On Apr 12, 2007 12:22 +0100, Anton Altaparmakov wrote:
On 12 Apr 2007, at 12:05, Andreas Dilger wrote:
I'm interested in getting input for implementing an ioctl to
efficiently map file extents holes (FIEMAP) instead of looping
over
. to all flamers: I am going to delete any non-technical flames
without replying so please do us all a favour and don't bother...
Thanks.
--
Anton Altaparmakov aia21 at cam.ac.uk (replace at with @)
Unix Support, Computing Service, University of Cambridge, CB2 3QH, UK
Linux NTFS maintainer, http
Dilger
Principal Software Engineer
Cluster File Systems, Inc.
--
Anton Altaparmakov aia21 at cam.ac.uk (replace at with @)
Unix Support, Computing Service, University of Cambridge, CB2 3QH, UK
Linux NTFS maintainer, http://www.linux-ntfs.org/
-
To unsubscribe from this list: send the line unsubscribe
,
Anton
--
Anton Altaparmakov aia21 at cam.ac.uk (replace at with @)
Unix Support, Computing Service, University of Cambridge, CB2 3QH, UK
Linux NTFS maintainer, http://www.linux-ntfs.org/
-
To unsubscribe from this list: send the line unsubscribe linux-fsdevel in
the body of a message to [EMAIL
.
+*/
This is a rather useless comment :) Better remove it and add a
proper
descriptions to Documentation/filesystems/vfs.txt and
Documentation/filesystems/Locking
Will do. Thanks!
--
Anton Altaparmakov aia21 at cam.ac.uk (replace at with @)
Unix Support, Computing Service, University of Cambridge
On 5 Mar 2007, at 14:37, Theodore Tso wrote:
On Sun, Mar 04, 2007 at 11:22:06PM +, Anton Altaparmakov wrote:
And I specifically did NOT update the initialized size in the inode
thus it will remain at its old value thus all new allocated blocks
will be considered as present
the file
size rather than just the allocated size). And that is it. No
zeroing needs to happen at all because we have not updated the
initialized size of the inode!
glibc can only dream of an implementation like this. (-;
Best regards,
Anton
--
Anton Altaparmakov aia21
would allocate a large consecutive region and
then go and drop random blocks from that region thus making the file
fragmented.
Best regards,
Anton
--
Anton Altaparmakov aia21 at cam.ac.uk (replace at with @)
Unix Support, Computing Service, University of Cambridge, CB2 3QH, UK
Linux NTFS
On 5 Mar 2007, at 00:32, Anton Altaparmakov wrote:
On 5 Mar 2007, at 00:16, Jörn Engel wrote:
On Sun, 4 March 2007 14:38:13 -0800, Ulrich Drepper wrote:
When you do it like this, who can the kernel/filesystem
*guarantee* that
when the data is written there actually is room on the harddrive
On Sun, 4 Feb 2007, Andrew Morton wrote:
On Sun, 4 Feb 2007 10:59:58 + (GMT) Anton Altaparmakov [EMAIL
PROTECTED] wrote:
On Sun, 4 Feb 2007, Andrew Morton wrote:
On Sun, 4 Feb 2007 09:51:07 +0100 (CET) Nick Piggin [EMAIL PROTECTED]
wrote:
2. If we find the destination page
PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Best regards,
Anton
--
Anton Altaparmakov aia21 at cam.ac.uk (replace at with @)
Unix Support, Computing Service, University of Cambridge, CB2 3QH, UK
Linux NTFS maintainer, http://www.linux-ntfs.org
have in the kernel.
Otherwise it looks great. We should make sure either Linus or Andrew
apply it.
Best regards,
Anton
--
Anton Altaparmakov aia21 at cam.ac.uk (replace at with @)
Unix Support, Computing Service, University of Cambridge, CB2 3QH, UK
Linux NTFS maintainer / IRC: #ntfs
Hi Linus,
On Fri, 19 Aug 2005, Linus Torvalds wrote:
On Fri, 19 Aug 2005, Anton Altaparmakov wrote:
Yes, sure. I have applied your patch to our 2.6.11.4 tree (with the one
liner change I emailed you just now) and have kicked off a compile.
Actually, hold on. The original patch had
the generic kernel
symlink mechanism any more. So it would be good to find and kill the
bug.
The patch is tested and does indeed make the hangs and bad page state
messages go away.
Best regards,
Anton
--
Anton Altaparmakov aia21 at cam.ac.uk (replace at with @)
Unix Support, Computing
On Fri, 2005-08-19 at 15:20 +0100, Al Viro wrote:
On Fri, Aug 19, 2005 at 12:14:48PM +0100, Anton Altaparmakov wrote:
There is a bug somewhere in 2.6.11.4 and I can't figure out where it is.
I assume it is present in older and newer kernels, too as the related
code hasn't changed much
just copied smbfs given ncpfs copies almost everything
smbfs does anyway...
Best regards,
Anton
--
Anton Altaparmakov aia21 at cam.ac.uk (replace at with @)
Unix Support, Computing Service, University of Cambridge, CB2 3QH, UK
Linux NTFS maintainer / IRC: #ntfs on irc.freenode.net
WWW
dentry *, char __user *, int);
Best regards,
Anton
--
Anton Altaparmakov aia21 at cam.ac.uk (replace at with @)
Unix Support, Computing Service, University of Cambridge, CB2 3QH, UK
Linux NTFS maintainer / IRC: #ntfs on irc.freenode.net
WWW: http://linux-ntfs.sf.net/ http://www
spotted, thanks. Fix will be in next ntfs release.
Best regards,
Anton
--
Anton Altaparmakov aia21 at cam.ac.uk (replace at with @)
Unix Support, Computing Service, University of Cambridge, CB2 3QH, UK
Linux NTFS maintainer / IRC: #ntfs on irc.freenode.net
WWW: http://linux-ntfs.sf.net
not a error. Instead of this print warning in dir.c, this
warning includes inode number for further investigation (e.g. with
ntfsinfo).
I applied something simillar to your patch to my private tree so it will
be in the next ntfs release. Thanks for the patch.
Best regards,
Anton
--
Anton
. (To complete
the picture the different local directories are actually the same remote
directory but mounted with access permissions for each user separately
using ncpfs.)
Best regards,
Anton
--
Anton Altaparmakov aia21 at cam.ac.uk (replace at with @)
Unix Support, Computing Service
...
Best regards,
Anton
--
Anton Altaparmakov aia21 at cam.ac.uk (replace at with @)
Unix Support, Computing Service, University of Cambridge, CB2 3QH, UK
Linux NTFS maintainer / IRC: #ntfs on irc.freenode.net
WWW: http://linux-ntfs.sf.net/ http://www-stu.christs.cam.ac.uk/~aia21/
, simply unmap the page
if you have mapped it and do a page_cache_release() on the page.
Hope this helps.
Best regards,
Anton
--
Anton Altaparmakov aia21 at cam.ac.uk (replace at with @)
Unix Support, Computing Service, University of Cambridge, CB2 3QH, UK
Linux NTFS maintainer / IRC: #ntfs
On Tue, 2005-03-01 at 23:17 +, David Woodhouse wrote:
On Mon, 2005-02-14 at 20:44 +, Anton Altaparmakov wrote:
So every time we get a concurrent clear_inode() and iget() for the same
inode what happens? We get your Failed to get bitmap attribute. every
time? Or can clear_inode
regards,
Anton
--
Anton Altaparmakov aia21 at cam.ac.uk (replace at with @)
Unix Support, Computing Service, University of Cambridge, CB2 3QH, UK
Linux NTFS maintainer / IRC: #ntfs on irc.freenode.net
WWW: http://linux-ntfs.sf.net/ http://www-stu.christs.cam.ac.uk/~aia21/
-
To unsubscribe
On Thu, 2005-02-10 at 14:48 +, Anton Altaparmakov wrote:
On Thu, 2005-02-10 at 15:42 +0100, Christoph Hellwig wrote:
On Thu, Feb 10, 2005 at 02:40:39PM +, Anton Altaparmakov wrote:
I am not sure what you mean. The VFS layer does reference counting on
inodes. I have no choice
On Thu, 2005-02-10 at 15:50 +0100, Christoph Hellwig wrote:
On Thu, Feb 10, 2005 at 02:48:26PM +, Anton Altaparmakov wrote:
If the igrab() were not done, it would be possible for clear_inode to be
called on the 'parent' inode whilst at the same time one or more attr
inodes (belonging
fops-write() otherwise?
Or have I missed some way in which the fops-write() case can be
optimized?
Best regards,
Anton
--
Anton Altaparmakov aia21 at cam.ac.uk (replace at with @)
Unix Support, Computing Service, University of Cambridge, CB2 3QH, UK
Linux NTFS maintainer / IRC: #ntfs
the write protection
thing.
Is your driver's source available to look at?
Best regards,
Anton
--
Anton Altaparmakov aia21 at cam.ac.uk (replace at with @)
Unix Support, Computing Service, University of Cambridge, CB2 3QH, UK
Linux NTFS maintainer / IRC: #ntfs on irc.freenode.net
WWW: http
On Wed, 2005-02-02 at 14:34 -0800, Andrew Morton wrote:
Anton Altaparmakov [EMAIL PROTECTED] wrote:
Below is a patch which adds a function
mm/filemap.c::find_or_create_pages(), locks a range of pages. Please see
the function description in the patch for details.
This isn't very
On Thu, 2005-02-03 at 02:47 -0800, Andrew Morton wrote:
Anton Altaparmakov [EMAIL PROTECTED] wrote:
On Wed, 2005-02-02 at 14:34 -0800, Andrew Morton wrote:
Anton Altaparmakov [EMAIL PROTECTED] wrote:
Below is a patch which adds a function
mm/filemap.c::find_or_create_pages
Hi,
On Thu, 27 Jan 2005, Andrew Morton wrote:
Anton Altaparmakov [EMAIL PROTECTED] wrote:
What would you propose can I do to perform the required zeroing in a
deadlock safe manner whilst also ensuring that it cannot happen that a
concurrent -readpage() will cause me to miss a page and thus
Hi Andrew,
Thanks a lot for your help! Some comments below...
On Thu, 27 Jan 2005, Andrew Morton wrote:
Anton Altaparmakov [EMAIL PROTECTED] wrote:
What would you propose can I do to perform the required zeroing in a
deadlock safe manner whilst also ensuring that it cannot happen
?
Thanks a lot in advance for any advice/suggestions you can give me...
Best regards,
Anton
--
Anton Altaparmakov aia21 at cam.ac.uk (replace at with @)
Unix Support, Computing Service, University of Cambridge, CB2 3QH, UK
Linux NTFS maintainer / IRC: #ntfs on irc.freenode.net
WWW: http://linux
to the i_data field? It
seems like a silly redundancy but there is probably something I am missing...
TIA for your time.
Best regards,
Anton
--
Nothing succeeds like success. - Alexandre Dumas
--
Anton Altaparmakov aia21 at cam.ac.uk (replace at with @)
Linux NTFS Maintainer / WWW: http
get_empty_inode() to accept the size (or slab cache) of the
inode required or something...
Just a thought...
Anton
--
Nothing succeeds like success. - Alexandre Dumas
--
Anton Altaparmakov aia21 at cam.ac.uk (replace at with @)
Linux NTFS Maintainer / WWW: http://sf.net/projects/linux-ntfs/
ICQ
--
Anton Altaparmakov aia21 at cam.ac.uk (replace at with @)
Linux NTFS Maintainer / WWW: http://sf.net/projects/linux-ntfs/
ICQ: 8561279 / WWW: http://www-stu.christs.cam.ac.uk/~aia21/
-
To unsubscribe from this list: send the line unsubscribe linux-fsdevel in
the body of a message to [EMAIL PROTECTED]
--
Nothing succeeds like success. - Alexandre Dumas
--
Anton Altaparmakov aia21 at cam.ac.uk (replace at with @)
Linux NTFS Maintainer / WWW: http://sf.net/projects/linux-ntfs/
ICQ: 8561279 / WWW: http://www-stu.christs.cam.ac.uk/~aia21/
--
Nothing succeeds like success. - Alexandre Dumas
, I/O speed is bound by the HD, not by the CPU, so whether the fs-code
is a bit slower or not will not make any difference in the actual disk
access case. (Cache access is of course a different matter.)
Just my 2p.
Regards,
Anton
--
Anton Altaparmakov aia21 at cam.ac.uk (replace
and works fine here.
Best regards,
Anton
--
Anton Altaparmakov aia21 at cam.ac.uk (replace at with @)
Linux NTFS maintainer / WWW: http://sourceforge.net/projects/linux-ntfs/
ICQ: 8561279 / WWW: http://www-stu.christs.cam.ac.uk/~aia21/
diff -urN linux-2.4.2-ac18-vanilla/fs/ext2/super.c
It was suggested to repost the below as a new thread and to cc: linux-fsdevel.
Any comments would be appreciated.
TIA,
Anton
So here goes:
At 12:41 08/03/01, Ingo Oeser wrote:
On Thu, Mar 08, 2001 at 11:39:27AM +, Anton Altaparmakov wrote:
[snip, attributions lost
Hans,
At 18:30 28/10/2000, Hans Reiser wrote:
Anton Altaparmakov wrote:
You can't possibly have both using the same API since you would then get
name collision on filesystems where both named streams and EAs are
supported. (And I haven't even mentioned EAs and named streams attached
:
Anton Altaparmakov wrote:
How would you distinguish the file filename/1 from the named stream filename/1?
I wouldn't, they are the same thing. If you need to emulate some filesystem which
needs to
distinguish them, then I would have the emulator (SAMBA?) call them
filename/1
vs.
filename
64 matches
Mail list logo
