Re: [PATCH 01/16] f2fs: add document
On Sunday 14 October 2012, Jaegeuk Kim wrote: > 2012-10-13 (토), 18:35 +, Arnd Bergmann: > > > + > > > +DESIGN > > > + > > > + > > > +On-disk Layout > > > +-- > > > + > > > +F2FS divides whole volume into a number of segments each of which size > > > is 2MB by > > > +default. A section is composed of consecutive segments, and a zone > > > consists of a > > > +set of sections. > > > > A segment size of 2MB should work fine for most eMMC, but there are a lot of > > devices using TLC (three bit per cell MLC) flash with 1.5/3/6/12 MB erase > > blocks, > > in particular cheap SD cards. Your design fundamentally won't work on those > > if you > > only allow power-of-two multiples of 2 MB. > > > > Would it be possible to change the segment size to 1.5 MB as a mkfs option? > > I realize that the space utilization would be slightly worse in that case, > > but if we allow power-of-two multiples of either 1.5 or 2 MB, that should > > cover > > almost all media on the market today, and most likely for the forseeable > > future. > > Yes, definitely right. > In the f2fs design, a segment with 2MB is a basic unit to manage the > whole storage space, but not to align with the erase block size. > Instead, we have a section for alignment. > If the erase block size is 1.5MB, I think it is worth to set the > section size to 6MB. > The only thing that I have to do is to support configuring the section > size as just multiples not power-of-two ones. > How do you think about this? I think I was confusing the terms 'section' and 'segment' here, I thought the segment was the larger of the two, sorry about that. For the 2011 generation of SD cards, changing the segment size to 1.5 MB would probably give a better performance, as it reduces the overhead from garbage collection compared to using 6 MB sections with 2 MB segments. In future devices, I assume we will not see erase blocks under 4 or 6 MB, so using arbitrary section sizes of multiples of 2 MB should indeed be good enough. It will also help us if we ever see 5-bit-per-cell flash and need 10 MB erase blocks, although I have not seen those on any roadmaps so far. > Yes, good point. > Actually, apart from the device side, I've concerned for a long time how > many logs should be needed and how to use them especially in order to > reduce the cleaning overhead efficiently in f2fs. > Finally, I got six logs. > > As you mentioned, it's ok to support 4 log areas as an option. > But, what I'm concerning is the cleaning overhead. > In terms of write amplification, is it really beneficial to reduce the > number of logs for flash storage even though the cleaning overhead > increases? > > BTW, if the cleaning overhead in 4 logs is not different from that in 6 > logs, absolutely we should use 4 logs. > This is basically dependant on the workload, and I think it needs more > research. I would expect that using 6 rather than 4 is almost always a measurable win when the hardware supports it, but a much bigger loss if the the hardware cannot support it. I believe we can measure the second case pretty well using Tixy's flashsim tool from http://yxit.co.uk/public/flash-performance/ by taking a blocktrace of the current code using 6 logs, and then simulating it on devices with 7 and 5 open erase blocks, respectively. On the former case it should report a write amplification fact of close to '1' for the FTL, in the latter case it will be significantly higher than that but also workload dependent. > > > +Each area manages the following contents. > > > +- CP File system information, bitmaps for valid NAT/SIT sets, > > > orphan > > > + inode lists, and summary entries of current active segments. > > > +- NATBlock address table for all the node blocks stored > > > in Main area. > > > +- SITSegment information such as valid block count and > > > bitmap for the > > > + validity of all the blocks. > > > +- SSASummary entries which contains the owner > > > information of all the > > > + data and node blocks stored in Main area. > > > +- Main Node and data blocks. > > > + > > > +In order to avoid misalignment between file system and flash-based > > > storage, F2FS > > > +aligns the start block address of CP with the segment size. Also, it > > > aligns the > > > +start block address of Main area with the zone size by reserving some > > > segments > > > +in SSA area. > > > > What do you do if the partition itself is misaligned? Do you align the > > start block > > address to the start of the partition or the start of the device? > > Yes, we got the start of the partition by ioctl. Ok, good. Is it possible to override this manually? I have seen (very few) devices in the past on which the first erase blo
Re: [PATCH 01/16] f2fs: add document
2012-10-13 (토), 18:35 +, Arnd Bergmann: > On Friday 05 October 2012 20:56:06 김재극 wrote: > > This adds a document describing the mount options, proc entries, usage, and > > design of Flash-Friendly File System, namely F2FS. > > Nice document! > > This is a lot like the design I came up with for an experimental file system > last year, so I'll try to go through and talk about the differences to > what I had. I believe there are a few points where you are missing > optimizations that I had and that could be added. > > > + > > +PROC ENTRIES > > + > > + > > +/proc/fs/f2fs/ contains information about partitions mounted as f2fs. For > > each > > +partition, a corresponding directory, named as its device name, is > > provided with > > +the following proc entries. > > + > > +- f2fs_stat major file system information managed by f2fs currently > > +- f2fs_sit_stat average SIT information about whole segments > > +- f2fs_mem_stat current memory footprint consumed by f2fs > > + > > +e.g., in /proc/fs/f2fs/sdb1/ > > Unrelated to the file system design, these should not be part of procfs at > all. You can probably convert them to debugfs files easily though and perhaps > even simplify the implementation in the process (I haven't looked at how it's > done at the moment). As greg pointed out this before, IMHO, this information is used not for debugging f2fs, but just showing the current status to users. So, I put this in procfs. But, as both of you and greg recommend this, I'd better reexamine the proc entries in consideration of debugfs at this moment. > > > + > > +DESIGN > > + > > + > > +On-disk Layout > > +-- > > + > > +F2FS divides whole volume into a number of segments each of which size is > > 2MB by > > +default. A section is composed of consecutive segments, and a zone > > consists of a > > +set of sections. > > A segment size of 2MB should work fine for most eMMC, but there are a lot of > devices using TLC (three bit per cell MLC) flash with 1.5/3/6/12 MB erase > blocks, > in particular cheap SD cards. Your design fundamentally won't work on those > if you > only allow power-of-two multiples of 2 MB. > > Would it be possible to change the segment size to 1.5 MB as a mkfs option? > I realize that the space utilization would be slightly worse in that case, > but if we allow power-of-two multiples of either 1.5 or 2 MB, that should > cover > almost all media on the market today, and most likely for the forseeable > future. Yes, definitely right. In the f2fs design, a segment with 2MB is a basic unit to manage the whole storage space, but not to align with the erase block size. Instead, we have a section for alignment. If the erase block size is 1.5MB, I think it is worth to set the section size to 6MB. The only thing that I have to do is to support configuring the section size as just multiples not power-of-two ones. How do you think about this? > > > +F2FS maintains logically six log areas. Except SB, all the log areas are > > managed > > +in a unit of multiple segments. SB is located at the beggining of the > > partition, > > +and there exist two superblocks to avoid file system crash. Other file > > system > > +metadata such as CP, NAT, SIT, and SSA are located in front part of the > > volume. > > +Main area contains file and directory data including their indices. > > This is almost identical to what I had come up with. > > The main difference is the number of log areas. Given that you need seven > erase > blocks (six log areas, plus a random access area), quite a number of devices > are excluded from working ideally. Making use of six log areas is definitely > a win if you manage to split the data well between hot/warm/cold blocks, but > on devices that can only handle 5, this is also clearly a loss. > > I understand that all Samsung eMMC handles this well, and so would the Samsung > Class 10 'Plus' SDHC cards. The Samsung Class 4 'Essential' cards can only do > 2 blocks of 6 MB plus the FAT area that you need for random access, so that > won't work well with your current design. > > Excluding some of your main competitor's eMMC seems more problematic. My view > is that if we include the file system, it should fundamentally work across > all devices in the industry. It's definitely ok to use 6 log areas by default > to optimize for sane devices like yours, but please consider offering at > least using just 4 log areas as an mkfs option in order to include all other > eMMC and the main SD card brands (many Sandisk, Lexar, and a bunch of the > noname ones). I don't think it's worth including the Toshiba/Phison/Kingston > SD card controllers tho
Re: [PATCH 01/16] f2fs: add document
On Friday 05 October 2012 20:56:06 김재극 wrote: > This adds a document describing the mount options, proc entries, usage, and > design of Flash-Friendly File System, namely F2FS. Nice document! This is a lot like the design I came up with for an experimental file system last year, so I'll try to go through and talk about the differences to what I had. I believe there are a few points where you are missing optimizations that I had and that could be added. > + > +PROC ENTRIES > + > + > +/proc/fs/f2fs/ contains information about partitions mounted as f2fs. For > each > +partition, a corresponding directory, named as its device name, is provided > with > +the following proc entries. > + > +- f2fs_stat major file system information managed by f2fs currently > +- f2fs_sit_stat average SIT information about whole segments > +- f2fs_mem_stat current memory footprint consumed by f2fs > + > +e.g., in /proc/fs/f2fs/sdb1/ Unrelated to the file system design, these should not be part of procfs at all. You can probably convert them to debugfs files easily though and perhaps even simplify the implementation in the process (I haven't looked at how it's done at the moment). > + > +DESIGN > + > + > +On-disk Layout > +-- > + > +F2FS divides whole volume into a number of segments each of which size is > 2MB by > +default. A section is composed of consecutive segments, and a zone consists > of a > +set of sections. A segment size of 2MB should work fine for most eMMC, but there are a lot of devices using TLC (three bit per cell MLC) flash with 1.5/3/6/12 MB erase blocks, in particular cheap SD cards. Your design fundamentally won't work on those if you only allow power-of-two multiples of 2 MB. Would it be possible to change the segment size to 1.5 MB as a mkfs option? I realize that the space utilization would be slightly worse in that case, but if we allow power-of-two multiples of either 1.5 or 2 MB, that should cover almost all media on the market today, and most likely for the forseeable future. > +F2FS maintains logically six log areas. Except SB, all the log areas are > managed > +in a unit of multiple segments. SB is located at the beggining of the > partition, > +and there exist two superblocks to avoid file system crash. Other file system > +metadata such as CP, NAT, SIT, and SSA are located in front part of the > volume. > +Main area contains file and directory data including their indices. This is almost identical to what I had come up with. The main difference is the number of log areas. Given that you need seven erase blocks (six log areas, plus a random access area), quite a number of devices are excluded from working ideally. Making use of six log areas is definitely a win if you manage to split the data well between hot/warm/cold blocks, but on devices that can only handle 5, this is also clearly a loss. I understand that all Samsung eMMC handles this well, and so would the Samsung Class 10 'Plus' SDHC cards. The Samsung Class 4 'Essential' cards can only do 2 blocks of 6 MB plus the FAT area that you need for random access, so that won't work well with your current design. Excluding some of your main competitor's eMMC seems more problematic. My view is that if we include the file system, it should fundamentally work across all devices in the industry. It's definitely ok to use 6 log areas by default to optimize for sane devices like yours, but please consider offering at least using just 4 log areas as an mkfs option in order to include all other eMMC and the main SD card brands (many Sandisk, Lexar, and a bunch of the noname ones). I don't think it's worth including the Toshiba/Phison/Kingston SD card controllers though, as they are basically broken for use with a proper file system anyway and attempting to support a single log area (plus random area in the front) would require tradeoffs that sacrifice performance on proper devices. > +Each area manages the following contents. > +- CP File system information, bitmaps for valid NAT/SIT sets, orphan > + inode lists, and summary entries of current active segments. > +- NATBlock address table for all the node blocks stored in > Main area. > +- SITSegment information such as valid block count and > bitmap for the > + validity of all the blocks. > +- SSASummary entries which contains the owner information of > all the > + data and node blocks stored in Main area. > +- Main Node and data blocks. > + > +In order to avoid misalignment between file system and flash-based storage, > F2FS > +aligns the st
Re: [PATCH 01/16] f2fs: add document
On Sat, Oct 6, 2012 at 9:40 PM, Jaegeuk Kim wrote: > 2012-10-06 (토), 09:19 +0200, Stefan Hajnoczi: >> > This adds a document describing the mount options, proc entries, usage, and >> > design of Flash-Friendly File System, namely F2FS. >> > >> > Signed-off-by: Jaegeuk Kim samsung.com> >> > --- >> > Documentation/filesystems/00-INDEX |2 + >> > Documentation/filesystems/f2fs.txt | 314 >> > >> > 2 files changed, 316 insertions(+) >> > create mode 100644 Documentation/filesystems/f2fs.txt >> > >> > diff --git a/Documentation/filesystems/00-INDEX >> > b/Documentation/filesystems/00-INDEX >> > index 8c624a1..ce5fd46 100644 >> > --- a/Documentation/filesystems/00-INDEX >> > +++ b/Documentation/filesystems/00-INDEX >> > @@ -48,6 +48,8 @@ ext4.txt >> > - info, mount options and specifications for the Ext4 filesystem. >> > files.txt >> > - info on file management in the Linux kernel. >> > +f2fs.txt >> > + - info and mount options for the F2FS filesystem. >> > fuse.txt >> > - info on the Filesystem in User SpacE including mount options. >> > gfs2.txt >> > diff --git a/Documentation/filesystems/f2fs.txt >> > b/Documentation/filesystems/f2fs.txt >> > new file mode 100644 >> > index 000..cd3f846 >> > --- /dev/null >> > +++ b/Documentation/filesystems/f2fs.txt >> > @@ -0,0 +1,314 @@ >> > + >> > +WHAT IS Flash-Friendly File System (F2FS)? >> > + >> > + >> > +NAND flash memory-based storage devices, such as SSD, eMMC, and SD cards, >> > have >> > +been widely being used for ranging from mobile to server systems. Since >> > they are >> > +known to have different characteristics from the conventional rotational >> > disks, >> > +a file system, an upper layer to the storage device, should adapt to the >> > changes >> > +from the sketch. >> > + >> > +F2FS is a file system exploiting NAND flash memory-based storage devices, >> > which >> > +is based on Log-structured File System (LFS). The design has been focused >> > on >> > +addressing the fundamental issues in LFS, which are snowball effect of >> > wandering >> > +tree and high cleaning overhead. >> > + >> > +Since a NAND flash memory-based storage device shows different >> > characteristic >> > +according to its internal geometry or flash memory management scheme aka >> > FTL, >> > +F2FS and its tools support various parameters not only for configuring >> > on-disk >> > +layout, but also for selecting allocation and cleaning algorithms. >> >> This is pretty high-level, can you list the main F2FS design points that are >> optimized for NAND flash characteristics? > > Ok, I'll summarize and supplement some major features in v2. Thanks! >> >> First I thought it's log-structured so it automatically performs write >> wear-leveling. But F2FS is intended to be used on top of FTL? > > Yes, F2FS works on top of FTL. The main goal of f2fs is to produce IOs > optimized to FTL as a best effort. So, I expect that F2FS would mitigate > the wear-out problem in FTL helpfully. > >> So the FTL >> already handles that, and also it appears F2FS is a hybrid between >> append-only >> and write in-place. > > Yes, F2FS is a hybrid, but in-place-writes will be occurred only when > there is not enough free space. So normally, it happens append-only. > > Anyway, do you concern the trade-off between wear-leveling and > in-place-writes? > IMHO, for better wear-leveling in FTL, file system cannot help writing > data in append-only as much as possible and aligning management units > between fs and FTL. I think that would be sufficiently effective to > reduce the wear-leveling overhead. Okay, thanks for explaining. Sounds like F2FS makes it easy for the FTL without taking over the responsibility of wear-leveling completely. >> >> Who will choose "various parameters" and select "allocation and cleaning >> algorithms" appropriate for the device? > > I think that the parameters will be determined mainly by system vendors. > They select flash chips for products so that they able to know also what > parameters are preferable from the chip vendor. > But, I think the default parameters are common enoughly for usual > environment. If the default parameters are usually fine then great. I was thinking about formatting existing SD cards with F2FS. Stefan -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 01/16] f2fs: add document
2012-10-06 (토), 09:19 +0200, Stefan Hajnoczi: > > This adds a document describing the mount options, proc entries, usage, and > > design of Flash-Friendly File System, namely F2FS. > > > > Signed-off-by: Jaegeuk Kim samsung.com> > > --- > > Documentation/filesystems/00-INDEX |2 + > > Documentation/filesystems/f2fs.txt | 314 > > > > 2 files changed, 316 insertions(+) > > create mode 100644 Documentation/filesystems/f2fs.txt > > > > diff --git a/Documentation/filesystems/00-INDEX > > b/Documentation/filesystems/00-INDEX > > index 8c624a1..ce5fd46 100644 > > --- a/Documentation/filesystems/00-INDEX > > +++ b/Documentation/filesystems/00-INDEX > > @@ -48,6 +48,8 @@ ext4.txt > > - info, mount options and specifications for the Ext4 filesystem. > > files.txt > > - info on file management in the Linux kernel. > > +f2fs.txt > > + - info and mount options for the F2FS filesystem. > > fuse.txt > > - info on the Filesystem in User SpacE including mount options. > > gfs2.txt > > diff --git a/Documentation/filesystems/f2fs.txt > > b/Documentation/filesystems/f2fs.txt > > new file mode 100644 > > index 000..cd3f846 > > --- /dev/null > > +++ b/Documentation/filesystems/f2fs.txt > > @@ -0,0 +1,314 @@ > > + > > +WHAT IS Flash-Friendly File System (F2FS)? > > + > > + > > +NAND flash memory-based storage devices, such as SSD, eMMC, and SD cards, > > have > > +been widely being used for ranging from mobile to server systems. Since > > they are > > +known to have different characteristics from the conventional rotational > > disks, > > +a file system, an upper layer to the storage device, should adapt to the > > changes > > +from the sketch. > > + > > +F2FS is a file system exploiting NAND flash memory-based storage devices, > > which > > +is based on Log-structured File System (LFS). The design has been focused > > on > > +addressing the fundamental issues in LFS, which are snowball effect of > > wandering > > +tree and high cleaning overhead. > > + > > +Since a NAND flash memory-based storage device shows different > > characteristic > > +according to its internal geometry or flash memory management scheme aka > > FTL, > > +F2FS and its tools support various parameters not only for configuring > > on-disk > > +layout, but also for selecting allocation and cleaning algorithms. > > This is pretty high-level, can you list the main F2FS design points that are > optimized for NAND flash characteristics? Ok, I'll summarize and supplement some major features in v2. > > First I thought it's log-structured so it automatically performs write > wear-leveling. But F2FS is intended to be used on top of FTL? Yes, F2FS works on top of FTL. The main goal of f2fs is to produce IOs optimized to FTL as a best effort. So, I expect that F2FS would mitigate the wear-out problem in FTL helpfully. > So the FTL > already handles that, and also it appears F2FS is a hybrid between append-only > and write in-place. Yes, F2FS is a hybrid, but in-place-writes will be occurred only when there is not enough free space. So normally, it happens append-only. Anyway, do you concern the trade-off between wear-leveling and in-place-writes? IMHO, for better wear-leveling in FTL, file system cannot help writing data in append-only as much as possible and aligning management units between fs and FTL. I think that would be sufficiently effective to reduce the wear-leveling overhead. > > Who will choose "various parameters" and select "allocation and cleaning > algorithms" appropriate for the device? I think that the parameters will be determined mainly by system vendors. They select flash chips for products so that they able to know also what parameters are preferable from the chip vendor. But, I think the default parameters are common enoughly for usual environment. On the other hand, configuring allocation and cleaning algorithms will be useful to researchers. It is obivous that the default algorithms may not be best according to various workloads, so I'd like to give a facility to easily add any new algorithms. > I wouldn't know what to parameter > values to use. > You can find the parameters from mount/format options in detail. > > +Index Structure > > +--- > > + > > +The key data structure to manage the data locations is a "node". As > > similar as > > +traditional file structures, F2FS has three types of node: inode, direct > > node, > > +indirect node. F2FS assigns 4KB to an inode block where contains 929 data > > block > > +indices, two direct node pointers, two indirect node pointers, and one > > double > > +indirect node pointer as described below. One direct node block contains > > 1018 > > +data blocks, and one indirect node block contains also 1018 node blocks. > > Thus, > > +O
Re: [PATCH 01/16] f2fs: add document
I'll apply this. Thanks, 2012-10-05 (금), 12:56 -0700, Randy Dunlap: > On 10/05/2012 04:56 AM, 김재극 wrote: > > > This adds a document describing the mount options, proc entries, usage, and > > design of Flash-Friendly File System, namely F2FS. > > > > Signed-off-by: Jaegeuk Kim > > --- > > Documentation/filesystems/00-INDEX |2 + > > Documentation/filesystems/f2fs.txt | 314 > > > > 2 files changed, 316 insertions(+) > > create mode 100644 Documentation/filesystems/f2fs.txt > > > > diff --git a/Documentation/filesystems/00-INDEX > > b/Documentation/filesystems/00-INDEX > > index 8c624a1..ce5fd46 100644 > > --- a/Documentation/filesystems/00-INDEX > > +++ b/Documentation/filesystems/00-INDEX > > @@ -48,6 +48,8 @@ ext4.txt > > - info, mount options and specifications for the Ext4 filesystem. > > files.txt > > - info on file management in the Linux kernel. > > +f2fs.txt > > + - info and mount options for the F2FS filesystem. > > fuse.txt > > - info on the Filesystem in User SpacE including mount options. > > gfs2.txt > > diff --git a/Documentation/filesystems/f2fs.txt > > b/Documentation/filesystems/f2fs.txt > > new file mode 100644 > > index 000..cd3f846 > > --- /dev/null > > +++ b/Documentation/filesystems/f2fs.txt > > @@ -0,0 +1,314 @@ > > + > > +WHAT IS Flash-Friendly File System (F2FS)? > > + > > + > > +NAND flash memory-based storage devices, such as SSD, eMMC, and SD cards, > > have > > +been widely being used for ranging from mobile to server systems. Since > > they are > > > > >been widely used for devices ranging from > or >been widely used for storage ranging from > > > +known to have different characteristics from the conventional rotational > > disks, > > +a file system, an upper layer to the storage device, should adapt to the > > changes > > +from the sketch. > > > > >from the start. > ? > > > + > > +F2FS is a file system exploiting NAND flash memory-based storage devices, > > which > > +is based on Log-structured File System (LFS). The design has been focused > > on > > +addressing the fundamental issues in LFS, which are snowball effect of > > wandering > > +tree and high cleaning overhead. > > + > > +Since a NAND flash memory-based storage device shows different > > characteristic > > +according to its internal geometry or flash memory management scheme aka > > FTL, > > +F2FS and its tools support various parameters not only for configuring > > on-disk > > +layout, but also for selecting allocation and cleaning algorithms. > > + > > +The file system formatting tool, "mkfs.f2fs", is available from the > > following > > +download page: http://sourceforge.net/projects/f2fs-tools/ > > + > > + > > +MOUNT OPTIONS > > + > > + > > +background_gc_off Turn off the cleaning operation, aka garbage > > collection, > > > > > Some people won't know what "aka" means, so how about: > > Turn off the cleaning operation [garbage collection] > > > + in background triggered when I/O subsystem is idle. > > +disable_roll_forward Disable the roll-forward recovery routine during > > SPOR. > > > > > what is SPOR? > > > +discardIssue discard/TRIM commands when a segment is > > cleaned. > > +no_heapDisable heap-style segment allocation in which > > finds free > > > > > drop: in > > > + segments for data from the beginning of main area, > > while > > + for node from the end of main area. > > +nouser_xattr Disable Extened User Attributes. Note: xattr is > > enabled > > > > > Extended > > > + by default if CONFIG_F2FS_FS_XATTR is selected. > > +noacl Disable POSIX Access Control List. Note: acl is > > enabled > > + by default if CONFIG_F2FS_FS_POSIX_ACL is selected. > > + > > + > > +PROC ENTRIES > > + > > + > > +/proc/fs/f2fs/ contains information about partitions mounted as f2fs. For > > each > > +partition, a corresponding directory, named as its device name, is > > provided with > > +the following proc entries. > > + > > +- f2fs_statmajor file system information managed by f2fs currently > > +- f2fs_sit_stataverage SIT information about whole segments > > > > > what is SIT? > > > +- f2fs_mem_statcurrent memory fo
Re: [PATCH 01/16] f2fs: add document
> This adds a document describing the mount options, proc entries, usage, and > design of Flash-Friendly File System, namely F2FS. > > Signed-off-by: Jaegeuk Kim samsung.com> > --- > Documentation/filesystems/00-INDEX |2 + > Documentation/filesystems/f2fs.txt | 314 > > 2 files changed, 316 insertions(+) > create mode 100644 Documentation/filesystems/f2fs.txt > > diff --git a/Documentation/filesystems/00-INDEX > b/Documentation/filesystems/00-INDEX > index 8c624a1..ce5fd46 100644 > --- a/Documentation/filesystems/00-INDEX > +++ b/Documentation/filesystems/00-INDEX > @@ -48,6 +48,8 @@ ext4.txt > - info, mount options and specifications for the Ext4 filesystem. > files.txt > - info on file management in the Linux kernel. > +f2fs.txt > + - info and mount options for the F2FS filesystem. > fuse.txt > - info on the Filesystem in User SpacE including mount options. > gfs2.txt > diff --git a/Documentation/filesystems/f2fs.txt > b/Documentation/filesystems/f2fs.txt > new file mode 100644 > index 000..cd3f846 > --- /dev/null > +++ b/Documentation/filesystems/f2fs.txt > @@ -0,0 +1,314 @@ > + > +WHAT IS Flash-Friendly File System (F2FS)? > + > + > +NAND flash memory-based storage devices, such as SSD, eMMC, and SD cards, > have > +been widely being used for ranging from mobile to server systems. Since they > are > +known to have different characteristics from the conventional rotational > disks, > +a file system, an upper layer to the storage device, should adapt to the > changes > +from the sketch. > + > +F2FS is a file system exploiting NAND flash memory-based storage devices, > which > +is based on Log-structured File System (LFS). The design has been focused on > +addressing the fundamental issues in LFS, which are snowball effect of > wandering > +tree and high cleaning overhead. > + > +Since a NAND flash memory-based storage device shows different characteristic > +according to its internal geometry or flash memory management scheme aka FTL, > +F2FS and its tools support various parameters not only for configuring > on-disk > +layout, but also for selecting allocation and cleaning algorithms. This is pretty high-level, can you list the main F2FS design points that are optimized for NAND flash characteristics? First I thought it's log-structured so it automatically performs write wear-leveling. But F2FS is intended to be used on top of FTL? So the FTL already handles that, and also it appears F2FS is a hybrid between append-only and write in-place. Who will choose "various parameters" and select "allocation and cleaning algorithms" appropriate for the device? I wouldn't know what to parameter values to use. > +Index Structure > +--- > + > +The key data structure to manage the data locations is a "node". As similar > as > +traditional file structures, F2FS has three types of node: inode, direct > node, > +indirect node. F2FS assigns 4KB to an inode block where contains 929 data > block > +indices, two direct node pointers, two indirect node pointers, and one double > +indirect node pointer as described below. One direct node block contains 1018 > +data blocks, and one indirect node block contains also 1018 node blocks. > Thus, > +One inode block (i.e., a file) covers: > + 4KB * (929 + 2 * 1018 + 2 * 1018 * 1018 + 1018 * 1018 * 1018) := 3.94TB. > + > + Inode block (4KB) > + |- data (929) > + |- direct node (2) > + | `- data (1018) > + |- indirect node (2) > + |`- direct node (1018) > + | `- data (1018) > + `- triple indirect node (1) > + `- indirect node (1018) > + `- direct node (1018) > + `- data (1018) Earlier it says "one double indirect node pointer" but this diagram shows a "triple indirect node". The diagram itself suggests this should really be "double indirect node" because it points to 1 indirect node. Stefan -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 01/16] f2fs: add document
On 10/05/2012 04:56 AM, 김재극 wrote: > This adds a document describing the mount options, proc entries, usage, and > design of Flash-Friendly File System, namely F2FS. > > Signed-off-by: Jaegeuk Kim > --- > Documentation/filesystems/00-INDEX |2 + > Documentation/filesystems/f2fs.txt | 314 > > 2 files changed, 316 insertions(+) > create mode 100644 Documentation/filesystems/f2fs.txt > > diff --git a/Documentation/filesystems/00-INDEX > b/Documentation/filesystems/00-INDEX > index 8c624a1..ce5fd46 100644 > --- a/Documentation/filesystems/00-INDEX > +++ b/Documentation/filesystems/00-INDEX > @@ -48,6 +48,8 @@ ext4.txt > - info, mount options and specifications for the Ext4 filesystem. > files.txt > - info on file management in the Linux kernel. > +f2fs.txt > + - info and mount options for the F2FS filesystem. > fuse.txt > - info on the Filesystem in User SpacE including mount options. > gfs2.txt > diff --git a/Documentation/filesystems/f2fs.txt > b/Documentation/filesystems/f2fs.txt > new file mode 100644 > index 000..cd3f846 > --- /dev/null > +++ b/Documentation/filesystems/f2fs.txt > @@ -0,0 +1,314 @@ > + > +WHAT IS Flash-Friendly File System (F2FS)? > + > + > +NAND flash memory-based storage devices, such as SSD, eMMC, and SD cards, > have > +been widely being used for ranging from mobile to server systems. Since they > are been widely used for devices ranging from or been widely used for storage ranging from > +known to have different characteristics from the conventional rotational > disks, > +a file system, an upper layer to the storage device, should adapt to the > changes > +from the sketch. from the start. ? > + > +F2FS is a file system exploiting NAND flash memory-based storage devices, > which > +is based on Log-structured File System (LFS). The design has been focused on > +addressing the fundamental issues in LFS, which are snowball effect of > wandering > +tree and high cleaning overhead. > + > +Since a NAND flash memory-based storage device shows different characteristic > +according to its internal geometry or flash memory management scheme aka FTL, > +F2FS and its tools support various parameters not only for configuring > on-disk > +layout, but also for selecting allocation and cleaning algorithms. > + > +The file system formatting tool, "mkfs.f2fs", is available from the following > +download page: http://sourceforge.net/projects/f2fs-tools/ > + > + > +MOUNT OPTIONS > + > + > +background_gc_off Turn off the cleaning operation, aka garbage > collection, Some people won't know what "aka" means, so how about: Turn off the cleaning operation [garbage collection] > +in background triggered when I/O subsystem is idle. > +disable_roll_forward Disable the roll-forward recovery routine during SPOR. what is SPOR? > +discardIssue discard/TRIM commands when a segment is cleaned. > +no_heapDisable heap-style segment allocation in which finds > free drop: in > + segments for data from the beginning of main area, > while > +for node from the end of main area. > +nouser_xattr Disable Extened User Attributes. Note: xattr is > enabled Extended > + by default if CONFIG_F2FS_FS_XATTR is selected. > +noacl Disable POSIX Access Control List. Note: acl is > enabled > + by default if CONFIG_F2FS_FS_POSIX_ACL is selected. > + > + > +PROC ENTRIES > + > + > +/proc/fs/f2fs/ contains information about partitions mounted as f2fs. For > each > +partition, a corresponding directory, named as its device name, is provided > with > +the following proc entries. > + > +- f2fs_stat major file system information managed by f2fs currently > +- f2fs_sit_stat average SIT information about whole segments what is SIT? > +- f2fs_mem_stat current memory footprint consumed by f2fs > + > +e.g., in /proc/fs/f2fs/sdb1/ > + > + > +USAGE > + > + > +1. Download userland tools > + > +2. Insmod f2fs.ko module: > + # insmod f2fs.ko > + > +3. Check the directory trying to m
[PATCH 01/16] f2fs: add document
This adds a document describing the mount options, proc entries, usage, and design of Flash-Friendly File System, namely F2FS. Signed-off-by: Jaegeuk Kim --- Documentation/filesystems/00-INDEX |2 + Documentation/filesystems/f2fs.txt | 314 2 files changed, 316 insertions(+) create mode 100644 Documentation/filesystems/f2fs.txt diff --git a/Documentation/filesystems/00-INDEX b/Documentation/filesystems/00-INDEX index 8c624a1..ce5fd46 100644 --- a/Documentation/filesystems/00-INDEX +++ b/Documentation/filesystems/00-INDEX @@ -48,6 +48,8 @@ ext4.txt - info, mount options and specifications for the Ext4 filesystem. files.txt - info on file management in the Linux kernel. +f2fs.txt + - info and mount options for the F2FS filesystem. fuse.txt - info on the Filesystem in User SpacE including mount options. gfs2.txt diff --git a/Documentation/filesystems/f2fs.txt b/Documentation/filesystems/f2fs.txt new file mode 100644 index 000..cd3f846 --- /dev/null +++ b/Documentation/filesystems/f2fs.txt @@ -0,0 +1,314 @@ + +WHAT IS Flash-Friendly File System (F2FS)? + + +NAND flash memory-based storage devices, such as SSD, eMMC, and SD cards, have +been widely being used for ranging from mobile to server systems. Since they are +known to have different characteristics from the conventional rotational disks, +a file system, an upper layer to the storage device, should adapt to the changes +from the sketch. + +F2FS is a file system exploiting NAND flash memory-based storage devices, which +is based on Log-structured File System (LFS). The design has been focused on +addressing the fundamental issues in LFS, which are snowball effect of wandering +tree and high cleaning overhead. + +Since a NAND flash memory-based storage device shows different characteristic +according to its internal geometry or flash memory management scheme aka FTL, +F2FS and its tools support various parameters not only for configuring on-disk +layout, but also for selecting allocation and cleaning algorithms. + +The file system formatting tool, "mkfs.f2fs", is available from the following +download page: http://sourceforge.net/projects/f2fs-tools/ + + +MOUNT OPTIONS + + +background_gc_off Turn off the cleaning operation, aka garbage collection, + in background triggered when I/O subsystem is idle. +disable_roll_forward Disable the roll-forward recovery routine during SPOR. +discardIssue discard/TRIM commands when a segment is cleaned. +no_heapDisable heap-style segment allocation in which finds free + segments for data from the beginning of main area, while + for node from the end of main area. +nouser_xattr Disable Extened User Attributes. Note: xattr is enabled + by default if CONFIG_F2FS_FS_XATTR is selected. +noacl Disable POSIX Access Control List. Note: acl is enabled + by default if CONFIG_F2FS_FS_POSIX_ACL is selected. + + +PROC ENTRIES + + +/proc/fs/f2fs/ contains information about partitions mounted as f2fs. For each +partition, a corresponding directory, named as its device name, is provided with +the following proc entries. + +- f2fs_statmajor file system information managed by f2fs currently +- f2fs_sit_stataverage SIT information about whole segments +- f2fs_mem_statcurrent memory footprint consumed by f2fs + +e.g., in /proc/fs/f2fs/sdb1/ + + +USAGE + + +1. Download userland tools + +2. Insmod f2fs.ko module: + # insmod f2fs.ko + +3. Check the directory trying to mount + # mkdir /mnt/f2fs + +4. Format the block device, and then mount as f2fs + # mkfs.f2fs -l label /dev/block_device + # mount -t f2fs /dev/block_device /mnt/f2fs + + +DESIGN + + +On-disk Layout +-- + +F2FS divides whole volume into a number of segments each of which size is 2MB by +default. A section is composed of consecutive segments, and a zone consists of a +set of sections. + +F2FS maintains logically six log areas. Except SB, all the log areas are managed +in a unit of multiple segme
