login
Search
In response to whether or not he had any objections to merging FUSE [story] into the mainline kernel, Andrew Morton [interview] offered some insight into what new features were slated for the upcoming 2.6.12 kernel. Andrew began, "I was planning on sending FUSE onto Linus in a week or two," going on to add "that and cpusets are the notable features which are 2.6.12 candidates."
Andrew then referred to several other patches currently in his -mm patchset [story], discussing their likelihood of being merged into the mainline kernel. He described crashdump [story] as seeming "permanently not-quite-ready". He noted that perfctr "works fine", but that it was "similar-to-but-different-from" the IA64 perfmon subsystem, and "might not be suitable for ppc64". Both nfsacl [thread] and the device-mapper multipath [thread] patches were deemed "OK for 2.6.12". Regarding cachefs, Andrew noted it "is a bit stuck because it's a ton of complex code and afs is the only user of it. Wiring it up to NFS would help." Finally, regarding whether or not he planned to merge reiser4 [story], he said this was "less clear" going on to add "once all the review comments have been addressed and we start seeing a bit of vendor pull for it, maybe."
From: Miklos Szeredi [email blocked] To: akpm Subject: [request for inclusion] Filesystem in Userspace Date: Wed, 02 Mar 2005 19:17:13 +0100 Hi Andrew! Do you have any objections to merging FUSE in mainline kernel? It's been in -mm for the 2.6.11 cycle, and the same code was released a month ago as FUSE-2.2. So it should have received a fair amount of testing, with no problems found so far. The one originally merged into -mm already addressed all major issues that people found (most importantly the OOM deadlock thing), and though there were some minor changes in the interface since then, I feel that the current kernel interface will stand up to the test of time. Thanks, Miklos
From: Andrew Morton [email blocked] Subject: Re: [request for inclusion] Filesystem in Userspace Date: Wed, 2 Mar 2005 12:31:23 -0800 Miklos Szeredi [email blocked] wrote: > > Do you have any objections to merging FUSE in mainline kernel? I was planning on sending FUSE into Linus in a week or two. That and cpusets are the notable features which are 2.6.12 candidates. - crashdump seems permanently not-quite-ready - perfctr works fine, but is rather deadlocked because it is similar-to-but-different-from ia64's perfmon, and might not be suitable for ppc64 (although things have gone quiet on the latter front). - nfsacl should be OK for 2.6.12 if Trond is OK with it. - cachefs is a bit stuck because it's a ton of complex code and afs is the only user of it. Wiring it up to NFS would help. - dm multipath is OK for 2.6.12 - reiser4 is less clear. Once all the review comments have been addressed and we start seeing a bit of vendor pull for it, maybe.
From: Christoph Hellwig [email blocked] Subject: Re: [request for inclusion] Filesystem in Userspace Date: Wed, 2 Mar 2005 22:19:01 +0000 On Wed, Mar 02, 2005 at 07:17:13PM +0100, Miklos Szeredi wrote: > Hi Andrew! > > Do you have any objections to merging FUSE in mainline kernel? > > It's been in -mm for the 2.6.11 cycle, and the same code was released > a month ago as FUSE-2.2. So it should have received a fair amount of > testing, with no problems found so far. > > The one originally merged into -mm already addressed all major issues > that people found (most importantly the OOM deadlock thing), and > though there were some minor changes in the interface since then, I > feel that the current kernel interface will stand up to the test of > time. Please give me or some other filesystem person some time to look over it, there were a few things that looked really fishy. And apologies for not having time to look at it earlier, but I'm a little bit too busy right now.
FUSE is great but...
a user should always be able to mount a device he can access on a directory he owns without beeing root, at least with some "stable" fs drivers (as fuse, that just runs a userspace program).
Another problem in linux is that if i have a fs non-fat on an usb key,
after i mount it, i may not be able to acces the files because they have a different owner, and this happens even if i am the owner of the device!
After soving this problems, fuse is going to be for linux something similar to what translators are for hurd :-)
Re: FUSE is great but...
a user should always be able to mount a device he can access on a directory he owns without beeing (sic) root
I agree. That's the behaviour I'm used to from my AIX days. On a multi-user system with a bunch of developer power users, you really want users to be able to do their own NFS mounts without having to bug the sysadmin.
Another problem in linux is that if i have a fs non-fat on an usb key,
after i mount it, i may not be able to acces the files because they have a different owner, and this happens even if i am the owner of the device!
That's a corollary to your first remark. When a user mounts a filesystem, all its files have to belong to that user. When root mounts the same device, file ownership should be taken into account.
And yes, FUSE sounds like a great step towards a solution to this problem. All you need is more FUSE filesystem drivers, such as NFS and fat/ext2/whatever, and simply having access to the network allows you to do an NFS mount as a user, and having access to the USB block device allows you to mount a fat/ext2/whatever filesystem on it. That solves the problem of unreliable NFS servers and unstable filesystem drivers messing with your kernel - you're doing it all in userland.
That's a corollary to your fi
That's a corollary to your first remark. When a user mounts a filesystem, all its files have to belong to that user. When root mounts the same device, file ownership should be taken into account.
Try this on for size:
/dev/hda1 is mounted as /etc
The user mounts /dev/hda1 as /home/user/tmp/mount
Now the user has access to /etc with all of the files owned by him.
*bzzt* wrong
"mount a device he can access"
you forgot that small detail from the original post.
if a user has access to the raw device, it's just a matter of convenience that he can mount the filesystem stored on the device with all the files owned by him.
mounting filesystems
Hi,
I don't know anything about FUSE except the little bit here.
But, I would think you can allow mounting raw devices which receive user rights if:
1.) A user cannot remount a raw device that is already mounted. That would stop a user from mounting / and /etc because they would presumably be mounted at bootup.
2.) root could do it, but then root is root, and I would think it would be more of an umount then mount operation and not mounting in 2 places.
It is probably a worthwhile convenience because if I got a hold of someone's cd or usb device and brought it to my pc where I am root, I would think I could mount it, and then would have to bother creating the necessary user id's on the cd on my system, which I could do. It's just a hassle. So this makes it easier to share media and if you need media security you would just have to encrypt your files.
Stan
There's still a potential security issue.
On some systems /boot isn't normally mounted so you don't accidentally screw it up. Under the proposed system, that would leave /boot mountable by users.
Not if the admin's on the ball
On my machine, the device node underlying /boot (/dev/evms/boot) is mode 640, owner root, group root. Thus, if I've understood the proposed system properly, a normal user cannot mount it even if they want to.
As I understand the proposals, users can mount any filesystem whose block device they can read as read-only, and can mount any filesystem whose block device they can both read and write as read-write. Filesystems already mounted cannot be remounted, and must be unmounted by root or the user who mounted them before they can be mounted again.
Thus, I can mount a CD-ROM read-only if I have read access to /dev/cdrom. I can't mount /boot at all, as I have no read or write access to it. Despite /dev/hda1 (a Windows partition) being readable by me, I cannot mount it, as it's already mounted on /mnt/windows; however, I can mount my USB stick, as it's readable and writeable by me, and not yet mounted.
That's a corollary to your fi
That's a corollary to your first remark. When a user mounts a filesystem, all its files have to belong to that user. When root mounts the same device, file ownership should be taken into account.
Well this seems like just the wrong thing to do - this defeats the purpose of having file permissions on remountable devices in multiuser environment (think mount -o remount / which could give user root permissions in this scenario)
Real solution is to make all files world writable on USB key - you have physical control over it, so data is reasonably secure.
Mhh
You cannot be that stupid. Previous post was only saying that if the user **owns** the device (like a usb key, hotplug will change permissions of /dev/sda1 if necessary), he should be able to mount it on a directory he owns with the ownership of the files to the user, so that he can modify his files comfortably, while when root mounts
/dev/hda1 the ownership will still be set to the true owner, and no user will be able to do anything on those file (because he doesn't own /dev/hda1)
v9fs
The hacks by fuse are by *far* better implemented as the concept of plan9. See v9fs.sf.net for a preliminary but ongoing port to linux.
Isn't pmount good enough for
Isn't pmount good enough for your needs?
feature lists?
Am i the only one that would love to see this kind of messages more often?
I try to read most changelogs when Linus anounces a new kernel release. I like to know when any feature is getting into the mainline, but it's _very_ hard to fish them under the lots and lots of bugfixes. For some high-profile features (UML, journaled filesystems) it was commented on several places, but for lesser known ones it's mostly guessing.
You are not alone!
I too have tried to do this however I stop after a few hundred lines or so.
"me too" post
a high-level summary would be nice for new kernel releases. it's easy to miss the forest lost among the individual trees.
if i'm looking for a specific bug fix, then it's easy to find what i need in the detailed changelog, but sometimes i just want a list of sub-system changes, but patch-level changes.
what andrew gave is even nicer: a roadmap. he's saying what we intends to release in the upcoming kernel version. that's even more daring, but very appreciated.
find kernel patches
THe best i foudn so far is:
http://ring.maffin.ad.jp/ring/newfiles/kernel.org.html
very handy to review a patch mentionned in say mm tree (the changelog are quite sparse).
Cheers
Alban
hi level summaries
a high-level summary would be nice for new kernel releases
Something like http://zdzichubg.jogger.pl/comment.php?eid=98612 ?
--
:wq
High Level Summary Here
Just goto LWN
personally, I think FUSE has
personally, I think FUSE has come really late, and KDE I/O Slaves (as well as the gnome
Crashdump has also come really late too... (Haven't pretty much all UNIX kernels had this for a LONG TIME?)
Crashdump is going to be awesome though.
One thing I've always thought linux doesn't do that would be really easy to implement is when the bootloader loads linux and maybe you accidently enter the wrong root= parameter, and then linux boots up, inits all the drivers, and then when it finally gets to mounting root fs, it kernel panics!
One thing it should do is print a list of the block devices and partitions (it already prints that, but you can't shift+pageup once it panics). But with something like crashdump, it would be possible to have a simple interface to let the user pick a block device, and either reload linux with the new root=, or just set root= to the currently running linux, and then continue on and mount root from there.
hopefully some kernel hacker with a lot of free time will read this and solve that annoying problem for the rest of us.
lol, I can't even finish my t
lol, I can't even finish my thoughts anymore, I meant to say, KDE I/O Slaves have already filled that need and will probably do a better job unless FUSE does some plan9/etc type stuff and have seperate name spaces for each program.
Also, I think crashdump would be really sweet if it was able to do OpenBSD's kernel's most useful feature:
when you kernel panic, start up the kernel debugger, play hangman with the kernel symbols
..but KDE I/O-slaves is no go
..but KDE I/O-slaves is no good in a KDE-free environment.
KDE I/O-slaves can be mounted with FUSE
KDE I/O-slaves can be mounted with FUSE.
What would you say about smth
What would you say about smth like kioslavefs for FUSE? ;)
Too Big
That it's not stable enough, that it's too bloated for something basic like filesystems... KIO infrastructure is big and wonderful, but it's too much for what the bare minimum fs needs
But with something like crash
But with something like crashdump, it would be possible to have a simple interface to let the user pick a block device, and either reload linux with the new root=, or just set root= to the currently running linux, and then continue on and mount root from there.
I already have something like this, it's called GRUB. Kernel panics, soft boot the system back to GRUB and tell it a different root device.
Let's slow things down!
At least we have Christoph Hellwig, who repeatedly made bad comments until ReiserFS4 lost nearly all features, his beloved ext3 could not compete with.
Now he said he will "look over it [FUSE], there were a few things that looked really fishy". Let's hope, FUSE will survive.
... an Anonymous Coward waiting for the possibility to mount anything which can be accessed through an KIO-slave.
Reiser4
I would think that implementing reiser 4 in the new kernel would be a good idea. I've heard from many people who have teseted it and majority points to its stability and speed. Also, I is there a posibility to improve SATA DVD drives. I've experienced many problems with that. Also, I've never used FUSE but from my understanding of how it works it might be a very usefull as for I too experienced some of the issues related to the usb devices and etc..
There is only one SATA DVD dr
There is only one SATA DVD drive available, which is from plextor. From what I've heard, they've been troublesome...so it may not be the linux kernel's fault...
I own that drive. It has a li
I own that drive. It has a little bit of trouble getting going when burning DVDs/CDs (a couple of initial IO-timeouts), but otherwise I've had no problems that have affected its reliability. It's a very nice drive and works well in Linux after a one-line patch to enable SATA ATAPI; it's just not as easy to boot off of due to lack of support in BIOSes. I think that not enabling support for it by default is not really valid at this point, since it works just fine and just needs more users to test it to flush out ALL the bugs.
FUSE and archives etc.
I love the idea of extending filesystems in the way that KDEIOSlaves do: I'm all for that sort of generalised 'metasolution' to problems. We need more of them in linux, such as generalised handlers/libraries for codecs, compression, archives, datatypes, volumes etc., along the lines of what Amigas had with their general compression/encryption libraries, datatype libraries, volume labels/assigns, etc.
But KDEIOSlaves has a major problem: even though you have an ability to look into archives with the zip: IOSlave, for example, the problem is that programs don't KNOW you can do that. So, when you double click on an archive, it gets opened, instead of being browsed like a directory.
So, does FUSE provide necessary hooks for a SMART filesystem? Or is there a better solution that does, which we might look to instead?