17 Mar, 2011
1 commit
-
Replace EXTRA_CFLAGS with ccflags-y. And change ntfs-objs to ntfs-y
for cleaner conditional inclusion.Signed-off-by: matt mooney
Acked-by: WANG Cong
Signed-off-by: Michal Marek
13 Jan, 2011
1 commit
-
Fix writev() to not keep writing the first segment over and over again
instead of moving onto subsequent segments and update the NTFS entry in
MAINTAINERS to reflect that Tuxera Inc. now supports the NTFS driver.Signed-off-by: Anton Altaparmakov
Signed-off-by: Linus Torvalds
13 Oct, 2007
1 commit
-
Big thanks go to Mathias Kolehmainen for reporting the bug, providing
debug output and testing the patches I sent him to get it working.The fix was to stop calling ntfs_attr_set() at mount time as that causes
balance_dirty_pages_ratelimited() to be called which on systems with
little memory actually tries to go and balance the dirty pages which tries
to take the s_umount semaphore but because we are still in fill_super()
across which the VFS holds s_umount for writing this results in a
deadlock.We now do the dirty work by hand by submitting individual buffers. This
has the annoying "feature" that mounting can take a few seconds if the
journal is large as we have clear it all. One day someone should improve
on this by deferring the journal clearing to a helper kernel thread so it
can be done in the background but I don't have time for this at the moment
and the current solution works fine so I am leaving it like this for now.Signed-off-by: Anton Altaparmakov
Signed-off-by: Linus Torvalds
18 Jan, 2007
1 commit
-
Signed-off-by: Anton Altaparmakov
23 Mar, 2006
1 commit
-
Signed-off-by: Anton Altaparmakov
24 Feb, 2006
1 commit
-
special casing the VOLUME_MODIFIED_BY_CHKDSK flag.
Signed-off-by: Anton Altaparmakov
11 Oct, 2005
1 commit
-
file operations ->write(), ->aio_write(), and ->writev() for regular
files. This replaces the old use of generic_file_write(), et al and
the address space operations ->prepare_write and ->commit_write.
This means that both sparse and non-sparse (unencrypted and
uncompressed) files can now be extended using the normal write(2)
code path. There are two limitations at present and these are that
we never create sparse files and that we only have limited support
for highly fragmented files, i.e. ones whose data attribute is split
across multiple extents. When such a case is encountered,
EOPNOTSUPP is returned.Signed-off-by: Anton Altaparmakov
04 Oct, 2005
1 commit
-
search context. This allows calling it with the mft record mapped.
Signed-off-by: Anton Altaparmakov
26 Sep, 2005
1 commit
-
restart pages in the journal without multi sector transfer protection
fixups (i.e. the update sequence array is empty and in fact does not
exist).Signed-off-by: Anton Altaparmakov
23 Sep, 2005
1 commit
-
since we otherwise get into a lock reversal deadlock if a read locked
runlist is passed in. In the process also change it to take an ntfs
inode instead of a vfs inode as parameter.Signed-off-by: Anton Altaparmakov
09 Sep, 2005
1 commit
-
Signed-off-by: Anton Altaparmakov
08 Sep, 2005
1 commit
-
- Support journals ($LogFile) which have been modified by chkdsk. This
means users can boot into Windows after we marked the volume dirty.
The Windows boot will run chkdsk and then reboot. The user can then
immediately boot into Linux rather than having to do a full Windows
boot first before rebooting into Linux and we will recognize such a
journal and empty it as it is clean by definition.
- Support journals ($LogFile) with only one restart page as well as
journals with two different restart pages. We sanity check both and
either use the only sane one or the more recent one of the two in the
case that both are valid.Signed-off-by: Anton Altaparmakov
26 Jun, 2005
1 commit
-
Signed-off-by: Anton Altaparmakov
25 Jun, 2005
1 commit
-
is active on the volume and we are mounting read-write or remounting
from read-only to read-write.Signed-off-by: Anton Altaparmakov
04 May, 2005
1 commit
-
Signed-off-by: Anton Altaparmakov
17 Apr, 2005
1 commit
-
Initial git repository build. I'm not bothering with the full history,
even though we have it. We can create a separate "historical" git
archive of that later if we want to, and in the meantime it's about
3.2GB when imported into git - space that would just make the early
git days unnecessarily complicated, when we don't have a lot of good
infrastructure for it.Let it rip!
