From: Charles D. <cd...@sp...> - 2005-01-13 20:54:57
|
Howdy. I recently experienced an issue where coLinux was unable to write to any of my raw partitions, though it was able to read them without problems. I eventually discovered that uninstalling ext2fsd (which had not had any partitions mounted at the time when the problem was observed) fixed the issue. Installing and starting ext2fsd after a coLinux instance is already running doesn't cause problems until reboot -- but at that time, ext2fsd (apparently) grabs all the drives, rendering coLinux unable to get a write lock on any of them. Until this issue is resolved, folks using coLinux to access raw partitions should probably avoid ext2fsd. |
From: Nuno L. <li...@xp...> - 2005-01-14 00:31:44
|
Charles Duffy, dando pulos de alegria, escreveu : > Until this issue is resolved, folks using coLinux to access raw partitions > should probably avoid ext2fsd. Note that this issue will never be solved. The only way to fix it would be to make ext2fsd to coop with colinux and that means patching both (meaning a special version of ext2fsd just for use with colinux). All ext2fs windows programs out there assume they are the only ones working with the image files/partitions. This leads to corruption of the fs if used concurrently. This is also why the linux NTFS driver will never work with colinux (can work, but with high corruption risk) and we need things like the experimental cofuse module, which use the host OS API to "talk" to the file system, avoiding so any corruption issues. Regards, ~Nuno Lucas |
From: Sam M. <pa...@gm...> - 2005-01-14 01:09:58
|
But there are options to work around this, for example Samba or NFS. If there is a fully working coLinux installation with networking, both Samba (for Windows and Linux) or NFS (mostly for Linux, but Windows clients and servers do exist, the Cygwin nfsd appears to be stable) are available to access partitions from either side of the gate, just requires a bit of setting up. On Fri, 14 Jan 2005 00:31:24 +0000, Nuno Lucas <li...@xp...> wrote: > Charles Duffy, dando pulos de alegria, escreveu : > > Until this issue is resolved, folks using coLinux to access raw partitions > > should probably avoid ext2fsd. > > Note that this issue will never be solved. > > The only way to fix it would be to make ext2fsd to coop with colinux and > that means patching both (meaning a special version of ext2fsd just for > use with colinux). > > All ext2fs windows programs out there assume they are the only ones > working with the image files/partitions. This leads to corruption of > the fs if used concurrently. > > This is also why the linux NTFS driver will never work with colinux (can > work, but with high corruption risk) and we need things like the > experimental cofuse module, which use the host OS API to "talk" to the > file system, avoiding so any corruption issues. > > Regards, > ~Nuno Lucas > > > ------------------------------------------------------- > The SF.Net email is sponsored by: Beat the post-holiday blues > Get a FREE limited edition SourceForge.net t-shirt from ThinkGeek. > It's fun and FREE -- well, almost....http://www.thinkgeek.com/sfshirt > _______________________________________________ > coLinux-users mailing list > coL...@li... > https://lists.sourceforge.net/lists/listinfo/colinux-users > |
From: Charles D. <cd...@sp...> - 2005-01-14 03:24:51
|
On Fri, 14 Jan 2005 00:31:24 +0000, Nuno Lucas wrote: > Note that this issue will never be solved. I certainly understand that it would never be resolved if one wished to have both ext2fsd and coLinux mounting the same drive at the same time. That's not my issue, though -- the partition I'm using ext2fsd to access isn't even on the same media as the partitions that coLinux mounts. ext2fsd is somehow these partitions anyhow. If its behaviour is changed, such that it only locks partitions that it's mounting, I would expect that it and coLinux could coexist on the same machine (albiet, of course not accessing the same partitions simultaniously). If there's a technical reason why this expectation is wrong, I'd be quite interested to hear it. > All ext2fs windows programs out there assume they are the only ones > working with the image files/partitions. This leads to corruption of the > fs if used concurrently. I would under no circumstances (except for a filesystem designed for concurrent write access -- GFS and kin, for instance) expect concurrent operation on the same partition. What I'm noting doesn't work is concurrent operation on the same machine, even when each is accessing a different partition. |
From: Nuno L. <ml-...@xp...> - 2005-01-14 16:39:38
|
Charles Duffy, dando pulos de alegria, escreveu : > I certainly understand that it would never be resolved if one wished to > have both ext2fsd and coLinux mounting the same drive at the same time. Sorry, I misunderstood your mail > That's not my issue, though -- the partition I'm using ext2fsd to access > isn't even on the same media as the partitions that coLinux mounts. > ext2fsd is somehow these partitions anyhow. If its behaviour is changed, > such that it only locks partitions that it's mounting, I would expect that > it and coLinux could coexist on the same machine (albiet, of course not > accessing the same partitions simultaniously). If there's a technical > reason why this expectation is wrong, I'd be quite interested to hear it. AFAIK, colinux only opens files after they are mounted (and does it in exclusive mode, to avoid corruption), and closes them after an umount (that's why you can "inject" files into colinux as http://wiki.colinux.org/cgi-bin/archiveascobd shows, or replace images dynamically by renaming them). It seems it's ext2fsd that maintains files/partitions open after use, maybe to speed further access. I'm only guessing here, as I never used ext2fsd. If that's true, then the solution passes by fixing ext2fsd to don't do this. Maybe someone else can confirm this, as I don't have any ext2 image to try ext2fsd on. Regards, ~Nuno Lucas |
From: Hilmar P. <hi...@we...> - 2005-01-14 16:56:33
|
On 14.01.05 Nuno Lucas (li...@xp...) wrote: Hi, > This is also why the linux NTFS driver will never work with colinux > (can work, but with high corruption risk) and we need things like > the experimental cofuse module, which use the host OS API to "talk" > to the file system, avoiding so any corruption issues. > I.e. I can't mount a Windows partition of my running Windows from coLinux even R/O? Thanks, Hilmar -- Today is the first day of the rest of your lossage. |
From: Nuno L. <ml-...@xp...> - 2005-01-14 19:10:19
|
Hilmar Preusse, dando pulos de alegria, escreveu : >>This is also why the linux NTFS driver will never work with colinux >>(can work, but with high corruption risk) and we need things like >>the experimental cofuse module, which use the host OS API to "talk" >>to the file system, avoiding so any corruption issues. > > I.e. I can't mount a Windows partition of my running Windows from > coLinux even R/O? Right. It has to do with how all operating systems cache disk data into memory for faster access, which can't be seen from colinux. Even a shared FAT32 partition is not safe, because of that caching. It would be possible to write an unsafe r/o module to read windows partitions, but why would anyone do it if it would always be an unsafe thing to use? There is the experimental (and buggy, right now) cofs driver to access windows partitions that will solve this issue, and there are a lot of different ways of doing it from the network (smbfs/cifs-samba, ssh, ftp, etc). Regards, ~Nuno Lucas |
From: Hilmar P. <hi...@we...> - 2005-01-15 13:38:15
|
On 14.01.05 Nuno Lucas (ml-...@xp...) wrote: > Hilmar Preusse, dando pulos de alegria, escreveu : Hi, > >I.e. I can't mount a Windows partition of my running Windows from > >coLinux even R/O? > > There is the experimental (and buggy, right now) cofs driver to > access windows partitions that will solve this issue, and there are > a lot of different ways of doing it from the network > (smbfs/cifs-samba, ssh, ftp, etc). > Sure, I'm doing it in the moment. I was just wondering about that and wanted to make sure, that I'm right. Smbfs I can use only by installing a samba server inside coLinux, which is quite overkill and with ssh the performance is not that good. I was hoping there would be another solution, but now I see there is no one. Thanks for reply, Hilmar -- Parsley is gharsley. -- Ogden Nash http://www.hilmar-preusse.de.vu/ |
From: Sam M. <pa...@gm...> - 2005-01-15 01:25:29
|
The problem comes in when another system writes to the same space AHEAD of the cache in the same area of the disk. It only needs to be a few bytes, and the cache then become useless because as the read operations progress, the cache is actually loading the new data, and then you get data corruption. And if we expand the caching concept, how much do you cache and how do you reflect updates made by other systems? Its much easier to use to provided tools to access Windows drives, usually via the network. Sam On Fri, 14 Jan 2005 19:09:42 +0000, Nuno Lucas <ml-...@xp...> wrote: > Hilmar Preusse, dando pulos de alegria, escreveu : > >>This is also why the linux NTFS driver will never work with colinux > >>(can work, but with high corruption risk) and we need things like > >>the experimental cofuse module, which use the host OS API to "talk" > >>to the file system, avoiding so any corruption issues. > > > > I.e. I can't mount a Windows partition of my running Windows from > > coLinux even R/O? > > Right. It has to do with how all operating systems cache disk data > into memory for faster access, which can't be seen from colinux. > > Even a shared FAT32 partition is not safe, because of that caching. > > It would be possible to write an unsafe r/o module to read windows > partitions, but why would anyone do it if it would always be an unsafe > thing to use? > > There is the experimental (and buggy, right now) cofs driver to access > windows partitions that will solve this issue, and there are a lot of > different ways of doing it from the network (smbfs/cifs-samba, ssh, ftp, > etc). > > Regards, > ~Nuno Lucas > > > ------------------------------------------------------- > The SF.Net email is sponsored by: Beat the post-holiday blues > Get a FREE limited edition SourceForge.net t-shirt from ThinkGeek. > It's fun and FREE -- well, almost....http://www.thinkgeek.com/sfshirt > _______________________________________________ > coLinux-users mailing list > coL...@li... > https://lists.sourceforge.net/lists/listinfo/colinux-users > |