Hi all, We''ve been thinking a little about a more integrated desktop presence for Tim Foster''s ZFS backup and snapshot services[1]. Here are some initial ideas about what a Phase 0 (snapshot only, not backup) user experience might look like... comments welcome. http://www.genunix.org/wiki/index.php/ZFS_Snapshot (I''m not subscribed to zfs-discuss, so please make sure either desktop-discuss or I remain cc''ed on any replies if you want me to see them...) Cheeri, Calum. [1] http://blogs.sun.com/timf/entry/zfs_automatic_for_the_people -- CALUM BENSON, Usability Engineer Sun Microsystems Ireland mailto:calum.benson at sun.com GNOME Desktop Team http://blogs.sun.com/calum +353 1 819 9771 Any opinions are personal and not necessarily those of Sun Microsystems
Hi Calum, heh, as it happens, I was tinkering with pygtk to see how difficult this would be :) Supposing I have a ZFS on my machine called root/export/home which is mounted on /export/home. Then I have my home dir as /export/home/chris. Say I only want to snapshot and backup /export/home/chris/Documents. I can''t create a snapshot of /export/home/chris/Documents as it is a directory, I have to create a snapshot of the parent ZFS, in this case /export/home/. So there isn''t really the granularity that the attached spec implies. Someone correct me if I''m wrong, but I just tried it and it didn''t work. I''ve had a bit of a look at ''Time Machine'' and I''d be more in favour of that style of backup. Just back up everything so I don''t have to think about it. My feeling is that picking individual directories out just causes confusion. Think of it this way: how much change is there on a daily basis on your desktop/laptop? Those snapshots aren''t going to grow very quickly. -Christian Calum Benson wrote:> Hi all, > > We''ve been thinking a little about a more integrated desktop presence > for Tim Foster''s ZFS backup and snapshot services[1]. Here are some > initial ideas about what a Phase 0 (snapshot only, not backup) user > experience might look like... comments welcome. > > http://www.genunix.org/wiki/index.php/ZFS_Snapshot > > (I''m not subscribed to zfs-discuss, so please make sure either > desktop-discuss or I remain cc''ed on any replies if you want me to > see them...) > > Cheeri, > Calum. > > [1] http://blogs.sun.com/timf/entry/zfs_automatic_for_the_people > >
Christian Kelly ??:> Hi Calum, > > heh, as it happens, I was tinkering with pygtk to see how difficult this > would be :) > > Supposing I have a ZFS on my machine called root/export/home which is > mounted on /export/home. Then I have my home dir as /export/home/chris. > Say I only want to snapshot and backup /export/home/chris/Documents. I > can''t create a snapshot of /export/home/chris/Documents as it is a > directory, I have to create a snapshot of the parent ZFS, in this case > /export/home/. So there isn''t really the granularity that the attached > spec implies. Someone correct me if I''m wrong, but I just tried it and > it didn''t work. > > I''ve had a bit of a look at ''Time Machine'' and I''d be more in favour of > that style of backup. Just back up everything so I don''t have to think > about it. My feeling is that picking individual directories out just > causes confusion. Think of it this way: how much change is there on a > daily basis on your desktop/laptop? Those snapshots aren''t going to grow > very quickly.Time Machine is storing all in the system by default, but you still can select some ones that you don''t like to store. And Time Machine don''t use ZFS. Here we will use ZFS snapshot, and what it''s working with is file system. In Nevada, the default file system is not ZFS, it means some directory is not ZFS, so seems you have to select some directory which is ZFS, and it''s impossible for you to store all, (some are not ZFS)...> > -Christian > > > > Calum Benson wrote: >> Hi all, >> >> We''ve been thinking a little about a more integrated desktop presence >> for Tim Foster''s ZFS backup and snapshot services[1]. Here are some >> initial ideas about what a Phase 0 (snapshot only, not backup) user >> experience might look like... comments welcome. >> >> http://www.genunix.org/wiki/index.php/ZFS_Snapshot >> >> (I''m not subscribed to zfs-discuss, so please make sure either >> desktop-discuss or I remain cc''ed on any replies if you want me to >> see them...) >> >> Cheeri, >> Calum. >> >> [1] http://blogs.sun.com/timf/entry/zfs_automatic_for_the_people >> >> > > _______________________________________________ > desktop-discuss mailing list > desktop-discuss at opensolaris.org-- Henry Zhang JDS Software Development, OPG Sun China Engineering & Research Institute Sun Microsystems, Inc. 10/F Chuang Xin Plaza, Tsinghua Science Park Beijing 100084, P.R. China Tel: +86 10 62673866 Fax: +86 10 62780969 eMail: hua.zhang at sun.com
> Time Machine is storing all in the system by default, but you still can > select some ones that you don''t like to store. And Time Machine don''t > use ZFS. > Here we will use ZFS snapshot, and what it''s working with is file > system. In Nevada, the default file system is not ZFS, it means some > directory is not ZFS, so seems you have to select some directory which > is ZFS, and it''s impossible for you to store all, (some are not ZFS)... >What I''m suggesting is that the configuration presents a list of pools and their ZFSes and that you have a checkbox, backup/don''t backup sort of an option. When you start having nested ZFSes it could get confusing as to what you are actually backing up if you start browsing down through the filesystem with the likes of nautilus. Take the example I gave before, where you have a pool called, say, pool1. In the pool you have two ZFSes: pool1/export and pool1/export/home. So, suppose the user chooses /export in nautilus and adds this to the backup list. Will the user be aware, from browsing through nautilus, that /export/home may or may not be backed up - depending on whether the -r (?) option is used. I guess what I''m saying is, how aware of the behavior of ZFS must the user be in order to use this backup system? -Christian
On Tue, 2007-11-20 at 13:35 +0000, Christian Kelly wrote:> What I''m suggesting is that the configuration presents a list of pools > and their ZFSes and that you have a checkbox, backup/don''t backup sort > of an option.That''s basically the (hacked-up) zenity GUI I have at the moment on my blog, download & install the packages and you''ll see - I think getting that in a proper tree-structure help ? Right now, there''s a bug in my gui, such that with: [X] tank [ ] tank/timf [ ] tank/timf/Documents [ ] tank/timf/Music Selecting "tank" implicitly marks the other filesystems for backup because of the way zfs properties inherit. (load the above gui again having just selected tank, and you''ll see the other filesystems being selected for you) Having said that, I like Calum''s ideas - and am happy to defer the decision about the gui to someone a lot more qualified than I in this area :-) I think that when browsing directories in nautilus, it would be good to have some sort of "backup" or "snapshot" icon (??la the little padlock in secure web-browsing sessions) to let you know this directory is being either backed up, and/or included in snapshots. cheers, tim -- Tim Foster, Sun Microsystems Inc, Solaris Engineering Ops http://blogs.sun.com/timf
On 20 Nov 2007, at 12:56, Christian Kelly wrote:> Hi Calum, > > heh, as it happens, I was tinkering with pygtk to see how difficult > this would be :) > > Supposing I have a ZFS on my machine called root/export/home which > is mounted on /export/home. Then I have my home dir as /export/home/ > chris. Say I only want to snapshot and backup /export/home/chris/ > Documents. I can''t create a snapshot of /export/home/chris/ > Documents as it is a directory, I have to create a snapshot of the > parent ZFS, in this case /export/home/. So there isn''t really the > granularity that the attached spec implies. Someone correct me if > I''m wrong, but I just tried it and it didn''t work.Right, for Phase 0 the thinking was that you''d really have to manually set up whatever pools and filesystems you required first. So in your example, you (or, perhaps, the Indiana installer) would have had to set up /export/home/chris/Documents as a ZFS filesystem in its own right before you could start taking snapshots of it. Were we to stick with this general design, in later phases, creating a new ZFS filesystem on the fly, and migrating the contents of the existing folder into to it, would hopefully happen behind the scenes when you selected that folder to be backed up. (That could presumably be quite a long operation, though, for folders with large contents.)> I''ve had a bit of a look at ''Time Machine'' and I''d be more in > favour of that style of backup. Just back up everything so I don''t > have to think about it. My feeling is that picking individual > directories out just causes confusion. Think of it this way: how > much change is there on a daily basis on your desktop/laptop? Those > snapshots aren''t going to grow very quickly.I have no problem looking at it from that angle if it turns out that''s what people want-- much of the UI would be fairly similar. But at the same time, I don''t necessarily always expect OSX users'' requirements to be the same as Solaris users'' requirements-- I''d especially like to hear from people who are already using Tim''s snapshot and backup services, to find out how they use it and what their needs are. Cheeri, Calum. -- CALUM BENSON, Usability Engineer Sun Microsystems Ireland mailto:calum.benson at sun.com GNOME Desktop Team http://blogs.sun.com/calum +353 1 819 9771 Any opinions are personal and not necessarily those of Sun Microsystems
On 20 Nov 2007, at 13:35, Christian Kelly wrote:> > Take the example I gave before, where you have a pool called, say, > pool1. In the pool you have two ZFSes: pool1/export and pool1/ > export/home. So, suppose the user chooses /export in nautilus and > adds this to the backup list. Will the user be aware, from browsing > through nautilus, that /export/home may or may not be backed up - > depending on whether the -r (?) option is used.I''d consider that to be a fairly strong requirement, but it''s not something I particularly thought through for the mockups. One solution might be to change the nautilus background for folders that are being backed up, another might be an indicator in the status bar, another might be emblems on the folder icons themselves. Which approach works best would probably depend on whether we expect most of the folders people are browsing reguarly to be backed up, or not backed up-- in general, you''d want any sort of indicator to show the less common state. Cheeri, Calum. -- CALUM BENSON, Usability Engineer Sun Microsystems Ireland mailto:calum.benson at sun.com GNOME Desktop Team http://blogs.sun.com/calum +353 1 819 9771 Any opinions are personal and not necessarily those of Sun Microsystems
Calum Benson wrote:> Right, for Phase 0 the thinking was that you''d really have to manually > set up whatever pools and filesystems you required first. So in your > example, you (or, perhaps, the Indiana installer) would have had to > set up /export/home/chris/Documents as a ZFS filesystem in its own > right before you could start taking snapshots of it. > > Were we to stick with this general design, in later phases, creating a > new ZFS filesystem on the fly, and migrating the contents of the > existing folder into to it, would hopefully happen behind the scenes > when you selected that folder to be backed up. (That could presumably > be quite a long operation, though, for folders with large contents.) >Ah, I see. So, for phase 0, the ''Enable Automatic Snapshots'' option would only be available for/work for existing ZFSes. Then at some later stage, create them on the fly.> I have no problem looking at it from that angle if it turns out that''s > what people want-- much of the UI would be fairly similar. But at the > same time, I don''t necessarily always expect OSX users'' requirements > to be the same as Solaris users'' requirements-- I''d especially like to > hear from people who are already using Tim''s snapshot and backup > services, to find out how they use it and what their needs are.Yes, absolutely, OSX users'' requirements probably vary wildly from those of a Solaris users''. I guess I fall into what we might call the ''lazy'' category of user ;) I''m aware of Tim''s tool, don''t use it though. -Christian
Calum Benson wrote:> On 20 Nov 2007, at 13:35, Christian Kelly wrote: >> Take the example I gave before, where you have a pool called, say, >> pool1. In the pool you have two ZFSes: pool1/export and pool1/ >> export/home. So, suppose the user chooses /export in nautilus and >> adds this to the backup list. Will the user be aware, from browsing >> through nautilus, that /export/home may or may not be backed up - >> depending on whether the -r (?) option is used. > > I''d consider that to be a fairly strong requirement, but it''s not > something I particularly thought through for the mockups. > > One solution might be to change the nautilus background for folders > that are being backed up, another might be an indicator in the status > bar, another might be emblems on the folder icons themselves.I think changing the background is a non starter since users can change the background already anyway. An emblem is good for the case where you are looking from "above" a dataset that is tagged for backup. An indicator in the status bar is good for when you are "in" a dataset that is tagged for backup. -- Darren J Moffat
On 20 Nov 2007, at 15:04, Darren J Moffat wrote:> Calum Benson wrote: >> On 20 Nov 2007, at 13:35, Christian Kelly wrote: >>> Take the example I gave before, where you have a pool called, >>> say, pool1. In the pool you have two ZFSes: pool1/export and >>> pool1/ export/home. So, suppose the user chooses /export in >>> nautilus and adds this to the backup list. Will the user be >>> aware, from browsing through nautilus, that /export/home may or >>> may not be backed up - depending on whether the -r (?) option is >>> used. >> I''d consider that to be a fairly strong requirement, but it''s not >> something I particularly thought through for the mockups. >> One solution might be to change the nautilus background for >> folders that are being backed up, another might be an indicator >> in the status bar, another might be emblems on the folder icons >> themselves. > > I think changing the background is a non starter since users can > change the background already anyway.You''re right that they "can", and while that probably does write it off, I wonder how many really do. (And we could possibly do something clever like a semi-opaque overlay anyway, we may not have to replace the background entirely.) All just brainstorming at this stage though, other ideas welcome :)> An emblem is good for the case where you are looking from "above" a > dataset that is tagged for backup. > > An indicator in the status bar is good for when you are "in" a > dataset that is tagged for backup.Yep, all true. Also need to bear in mind that nowadays, with the (fairly) new nautilus treeview, you can potentially see both "in" and "above" at the same time, so any solution would have to work elegantly with that view too. Cheeri, Calum. -- CALUM BENSON, Usability Engineer Sun Microsystems Ireland mailto:calum.benson at sun.com GNOME Desktop Team http://blogs.sun.com/calum +353 1 819 9771 Any opinions are personal and not necessarily those of Sun Microsystems
On 20 Nov 2007, at 14:31, Christian Kelly wrote:> > Ah, I see. So, for phase 0, the ''Enable Automatic Snapshots'' option > would only be available for/work for existing ZFSes. Then at some > later > stage, create them on the fly.Yes, that''s the scenario for the mockups I posted, anyway... if the requirements are bogus, then of course we''ll have to change them :) My original mockup did allow you to create a pool/filesystem on the fly if required, but it felt like the wrong place to be doing that-- if you could understand the dialog to do that, you would probably know how to do it better on the command line anyway. Longer term, I guess we might be wanting to ship some sort of ZFS management GUI that might be better suited to that sort of thing (maybe like the Nexenta app that Roman mentioned earlier, but I haven''t really looked at that yet...) Cheeri, Calum. -- CALUM BENSON, Usability Engineer Sun Microsystems Ireland mailto:calum.benson at sun.com GNOME Desktop Team http://blogs.sun.com/calum +353 1 819 9771 Any opinions are personal and not necessarily those of Sun Microsystems
Calum Benson wrote:> You''re right that they "can", and while that probably does write it off, > I wonder how many really do. (And we could possibly do something clever > like a semi-opaque overlay anyway, we may not have to replace the > background entirely.)Almost everyone I''ve seen using the filemanager other than myself has done this :-) If you do a semi-opaque overlay thats going to require lots of colour selection stuff - plus what if the background is a complex image (why people do this I don''t know but I''ve seen it done).>> An emblem is good for the case where you are looking from "above" a >> dataset that is tagged for backup. >> >> An indicator in the status bar is good for when you are "in" a dataset >> that is tagged for backup. > > Yep, all true. Also need to bear in mind that nowadays, with the > (fairly) new nautilus treeview, you can potentially see both "in" and > "above" at the same time, so any solution would have to work elegantly > with that view too.I would expect emblem in the tree and status bar indicator for the non tree part. -- Darren J Moffat
-----Original Message----- From: zfs-discuss-bounces at opensolaris.org [mailto:zfs-discuss-bounces at opensolaris.org] On Behalf Of Calum Benson Sent: Tuesday, November 20, 2007 11:12 AM To: Darren J Moffat Cc: Henry Zhang; zfs-discuss at opensolaris.org; Desktop discuss; Christian Kelly Subject: Re: [zfs-discuss] [desktop-discuss] ZFS snapshot GUI On 20 Nov 2007, at 15:04, Darren J Moffat wrote:> Calum Benson wrote: >> On 20 Nov 2007, at 13:35, Christian Kelly wrote: >>> Take the example I gave before, where you have a pool called, >>> say, pool1. In the pool you have two ZFSes: pool1/export and >>> pool1/ export/home. So, suppose the user chooses /export in >>> nautilus and adds this to the backup list. Will the user be >>> aware, from browsing through nautilus, that /export/home may or >>> may not be backed up - depending on whether the -r (?) option is >>> used. >> I''d consider that to be a fairly strong requirement, but it''s not >> something I particularly thought through for the mockups. >> One solution might be to change the nautilus background for >> folders that are being backed up, another might be an indicator >> in the status bar, another might be emblems on the folder icons >> themselves. > > I think changing the background is a non starter since users can > change the background already anyway.You''re right that they "can", and while that probably does write it off, I wonder how many really do. (And we could possibly do something clever like a semi-opaque overlay anyway, we may not have to replace the background entirely.) All just brainstorming at this stage though, other ideas welcome :)> An emblem is good for the case where you are looking from "above" a > dataset that is tagged for backup. > > An indicator in the status bar is good for when you are "in" a > dataset that is tagged for backup.Yep, all true. Also need to bear in mind that nowadays, with the (fairly) new nautilus treeview, you can potentially see both "in" and "above" at the same time, so any solution would have to work elegantly with that view too. Cheeri, Calum. -- CALUM BENSON, Usability Engineer Sun Microsystems Ireland mailto:calum.benson at sun.com GNOME Desktop Team http://blogs.sun.com/calum +353 1 819 9771 Any opinions are personal and not necessarily those of Sun Microsystems _______________________________________________ zfs-discuss mailing list zfs-discuss at opensolaris.org http://mail.opensolaris.org/mailman/listinfo/zfs-discuss
How does the ability to set a snapshot schedule for a particular *file* or *folder* interact with the fact that ZFS snapshots are on a per-filesystem basis? This seems a poor fit. If I choose to snapshot my "Important Documents" folder every 5 minutes, that''s implicitly creating snapshots of my "Giant Video Downloads" folder every 5 minutes too, if they''re both in the same file system. It seems unwise not to expose this to the user. One possibility would be for the "enable snapshots" menu item to implicitly apply to the root of the file system in which the selected item is. So in the example shown, right-clicking on "Documents" would bring up a dialog labeled something like "Automatic snapshots for /home/cb114949". = I don''t think it''s a good idea to replace "Enable Automatic Snapshots" by "Restore from Snapshot" because there''s no obvious way to "Disable Automatic Snapshots" (or change their properties). (It appears one could probably do that from the properties dialog, but that''s certainly not obvious to a user who has turned this on using the menu and now wants to make a change -- if you can turn it on in the menu, you should be able to turn it off in the menu too.) = If "Roll back" affects the whole file system, it definitely should NOT be an option when right-clicking on a file or folder within the file system! This is a recipe for disaster. I would not present this as an option at all -- it''s already in the "Restore Files" dialog. Also, "All files will be restored" is not a good description for rollback. That really means "All changes since the selected snapshot will be lost." I can readily imagine a user thinking, "I deleted three files, so if I choose to restore all files, I''ll get those three back [without losing the other work I''ve done]." = Just a few random comments. This message posted from opensolaris.org
Very good points Rang, I''m going to add to them with a few of my own. It should be possible to restore individual files rather than rolling back the snapshot and I guess that''s what was meant here. I think the terminology in the original post may not be too clear. However, my impression reading this is that this is an application that runs directly on the machine. If so, we''re missing an opportunity here. Solaris isn''t really an end user OS, it''s more of a server OS. If you are going to implement a nice GUI for restoring files from a snapshot, you really want that to work over a network as well as on the local machine. Ironically, if you''re a windows user you already have that ability over the network with Solaris. Run ZFS and Samba and windows users can use Microsoft''s Shadow Copy Client to right-click any file and easily restore it from a snapshot: http://helpdesk.its.uiowa.edu/windows/instructions/shadowcopy.htm What''s really needed is a way to do that on Solaris and Linux machines over the network. Integration with Apple''s time machine would be great too (especially as it sounds like they may be making it compatible with ZFS), but unless somebody high up in Sun speaks to Apple I don''t see that happening. So you need two UI''s: - On the server side a simple UI is needed for creating and scheduling snapshots of the filesystem. Tim Foster''s service would be a good starting point for that: http://blogs.sun.com/timf/entry/zfs_automatic_for_the_people - On the client side a simple UI is needed that allows users to easily see previous versions of files and folders, and either restore them in place or copy old versions to a new location. And the client side of this would want to be capable of running either locally or over the network. I think you could probably bodge this by virtue of the fact that you can browse the files in a snapshot. Performance would probably be slow however and I''ve no doubt that far better performance could be achieved with hooks into ZFS (which incidentally would benefit apple if they want to move time machine to ZFS). That kind of thing is way outside my experience however, but it would be good if somebody at Sun could think about it. This message posted from opensolaris.org
Hi, In respect of snapshots :- a) should the snapshot process it self be modified to allow restoring of individual files via zfs rollback b) should there be a zfs rollfile to selectively restore files from a snapshot c) should there be a zfs purge which would allow file(s) to be removed from zfs including all snapshots Ross wrote:> Very good points Rang, I''m going to add to them with a few of my own. > > It should be possible to restore individual files rather than rolling back the snapshot and I guess that''s what was meant here. I think the terminology in the original post may not be too clear. > > However, my impression reading this is that this is an application that runs directly on the machine. If so, we''re missing an opportunity here. Solaris isn''t really an end user OS, it''s more of a server OS. If you are going to implement a nice GUI for restoring files from a snapshot, you really want that to work over a network as well as on the local machine. > > Ironically, if you''re a windows user you already have that ability over the network with Solaris. Run ZFS and Samba and windows users can use Microsoft''s Shadow Copy Client to right-click any file and easily restore it from a snapshot: http://helpdesk.its.uiowa.edu/windows/instructions/shadowcopy.htm > > What''s really needed is a way to do that on Solaris and Linux machines over the network. Integration with Apple''s time machine would be great too (especially as it sounds like they may be making it compatible with ZFS), but unless somebody high up in Sun speaks to Apple I don''t see that happening. > > So you need two UI''s: > > - On the server side a simple UI is needed for creating and scheduling snapshots of the filesystem. Tim Foster''s service would be a good starting point for that: http://blogs.sun.com/timf/entry/zfs_automatic_for_the_people > > - On the client side a simple UI is needed that allows users to easily see previous versions of files and folders, and either restore them in place or copy old versions to a new location. > > And the client side of this would want to be capable of running either locally or over the network. > > I think you could probably bodge this by virtue of the fact that you can browse the files in a snapshot. Performance would probably be slow however and I''ve no doubt that far better performance could be achieved with hooks into ZFS (which incidentally would benefit apple if they want to move time machine to ZFS). > > That kind of thing is way outside my experience however, but it would be good if somebody at Sun could think about it. > > > This message posted from opensolaris.org > _______________________________________________ > zfs-discuss mailing list > zfs-discuss at opensolaris.org > http://mail.opensolaris.org/mailman/listinfo/zfs-discuss > > ______________________________________________________________________ > This email has been scanned by the MessageLabs Email Security System. > For more information please visit http://www.messagelabs.com/email > ______________________________________________________________________ > >-- Regards Russell
hi there, On Thu, 2007-11-22 at 00:53 -0800, Ross wrote:> It should be possible to restore individual files rather than rolling > back the snapshot and I guess that''s what was meant here. I think the > terminology in the original post may not be too clear.Yep, I agree.> However, my impression reading this is that this is an application > that runs directly on the machine. If so, we''re missing an > opportunity here. Solaris isn''t really an end user OS, it''s more of a > server OS. If you are going to implement a nice GUI for restoring > files from a snapshot, you really want that to work over a network as > well as on the local machine.Definitely - you can do that now over NFS. Here space/timf is a ZFS dataset on my desktop machine, haiiro. On "spoon" a client machine, I browse to haiiro''s NFS shares: timf at spoon[1] cd /net/haiiro/space/timf/.zfs timf at spoon[3] cd snapshot timf at spoon[4] ls -1 total 56 3 backup-2007-09-25-16-21-05/ 3 backup-2007-09-25-16-49-42/ 3 backup-2007-09-25-16-53-37/ 3 backup-2007-09-25-17-35-07/ . . etc. Those are all snapshots taken on the filesystems on haiiro. You can also mkdir inside a remote directories to create snapshots, assuming you''ve been delegated that permission: timf at spoon[5] mkdir new timf at spoon[6] ssh timf at haiiro /usr/sbin/zfs list space/timf at new NAME USED AVAIL REFER MOUNTPOINT space/timf at new 0 - 5,18G -> - On the client side a simple UI is needed that allows users to > easily see previous versions of files and folders, and either restore > them in place or copy old versions to a new location.And that''s what this is all about - trying to find a cleaner way than http://blogs.sun.com/timf/entry/zfs_on_your_desktop to tie the client and server sides together. cheers, tim -- Tim Foster, Sun Microsystems Inc, Solaris Engineering Ops http://blogs.sun.com/timf