|
From: Anton A. <ai...@ca...> - 2004-05-09 20:56:00
|
On Sat, 8 May 2004, Szakacsits Szabolcs wrote: > On Sat, 8 May 2004, Anton Altaparmakov wrote: > > On Sat, 8 May 2004, Szakacsits Szabolcs wrote: > Do you remember when over a year ago we debugged and fixed a deadlock what > people sometimes reported? > > http://archives.mandrakelinux.com/cooker/2003-02/msg00285.php > http://archives.mandrakelinux.com/cooker/2003-02/msg00538.php I don't remember to be honest and I cannot open archives.mandrakelinux.com a all. )-: > Isn't it possible you still mean this bug, just forgot about it that's why > you can't reproduce anymore? That depends what it was but I very much doubt it as when the deadlock appeared it was just when I had implemented the inode write out in the VM page writeback (writepage()) code path. The code deadlocked always after writing something after a few seconds (the VM tried to write out the dirty pages). I then got very busy and development stopped. I revisited the code several months later and the deadlock was still occuring but not always. I then got busy again and only went back to trying it recently (a few months ago now I think) and now it didn't deadlock again which makes me wonder if something in the kernel changed and/or got fixed and that was the cause for the deadlocks... I don't know but I would rather not just take the code from ntfs-2.5-devel into ntfs-2.6 to be on the safe side. Also, I have had some ideas as to how to improve on the situation due to VM improvements. My ideas should remove quite a lot of code from the one in ntfs-2.5-devel and they should remove any eventual deadlocks, too. but we will see... > > I am afraid it is quite possible that my plans have only ever existed > > on IRC and/or private emails... > > Potential sponsors would be interested also, I'm quite sure ;-) (-: > > > Your original sentences suggested for me that significant changes, new big > > > features are coming soon what apparently I misunderstood. > > > > Not that soon, no. Although having resident file overwrite is a pretty > > important feature. > > I totally agree. > > Probably I wasn't clear either, I do know a lot of work is needed still > and even something that looks a trival feature or non-feature can take a > long time to get done properly by careful, hard work. I just thought you > became a beneficent millionaire or someone seriously started to sponsor > the development ;-) I wish I had become a millionaire! (-: I found devote myself to Linux fulltime on the spot... (-: And yes, proper funding for NTFS development would be rather nice... > > And being able to write mft records / dirty inodes is a pretty big > > feature for the driver internals as it allows all sorts of code to be > > added in various places to do different things. > > Of course I agree. I wasn't aware this code already exists in the > development tree, I thought it's the same as the one in the kernel so > I've never checked it out. > > Anyway, the above is a very good news. > > > E.g. allows to start on file truncation support which means you can > > write and resize files. > > Yes, create, unlink, truncate would be the most important next steps, > I think. > > > It also allows work on access time updating to start. And if anyone > > is so inclined (FlatCap was working on this but he is deNTFSing his > > life at the moment...) directory writing code can start to be added. > > All sorts of things can start happenning really... > > Anybody is working on anything related? Either user space or kernel space? > I'm aware of your ntfstruncate but nothing else. FlatCap did a lot of work on understanding how the B-trees (apparently a B*tree and not a B+tree as Microsoft claim). I am not too sure about this stuff. You would need to ask him. I know he has some stuff in the tng-support BK repository relating to the Btree business... > > I will get back to you at a later time with what my personal plans for > > working on the driver look like. > > Great. These should be summarzed on the web also somehow IMHO. Something > that what and how people could help. Not necessarily kernel coding but > also updating, cleaning documantation, web pages, testing, etc. There > would be many ways to help out. I will try and come up with something, maybe tomorrow, in email form and if worst comes to worst I/someone can always just cut and paste the email onto our webpages in the Status page or something... Don't know if I will have time as I am rather busy at the moment and I also need to make new releases for both the driver and ntfsprogs with the fixes for the decompression code I did this weekend. Two bugs in driver's compress.c and three in libntfs' compress.c that showed up by the bug report from Marcin Gibula (I know the l is not supposed to be an l but I don't think pine will allow me to write the correct character). I really also ought to run the old compress.c and the old compress.c though MD5 summing lots of compressed files to make sure I haven't broken anything with my fixes but I am not sure I will have time for that. I might just release it and wait for people to complain. My driver fixes certainly made things work ok for Marcin. 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/ |
