unlink 시에는 negative dentry 가 생기지 않는다

lookup 시에 찾으려는 file 이 없으면 dentry 가 가르키는 (vfs) inode 를 NULL 로 만들어둔다.

이런 dentry는 nagative dentry 가 되어서 다음 번 lookup에 활용된다.


unlink 시에는 inode 를 없애야 하는데, 이 때 dentry 가 가르키는 inode만 없애는 것이 아니라

dentry 까지 같이 free 한다.

linux getdents (readdir) 의 callback filldir 에 대하여

readdir 
linux 에서 directory file 의 내용을 읽기 위하여 사용하는 API 이다.


대표적으로는 ls 가 readdir을 통해서 구현되었다고 생각하면 된다.
실제로 사용하는 syscall 은 getdents 이다. 


이름으로 보면 getdent's' 복수형이다. 
즉, readdir을 directroy file 내용을 하나씩 읽어오고
getdents는 여러개씩 읽어오도록 되어있다.


당연히 getdents 가 성능이 더 좋다.


내부의 구현을 보면 둘다 vfs_readdir() 을 부르게 되는데, 다만 이 때 넘겨주는 callback fuction 인 filler (readdir은  fillonedir, getdents는 filldir) 의 차이로 구분하게 된다.

여기서 남기고 싶은 이야기는


getdents 가 넘거주는 filldir 에 d_type 에 대한 것이다.



static int filldir(void * __buf, const char * name, int namlen, loff_t offset,
  u64 ino, unsigned int d_type)


뭐하는데 쓰이는 지 봤는데, 오로지 ext2,3,4, Btrfs 만 을 위한 field 같이 보인다.
다른 인자들은 특별할 것이 없이 fs 가 name, len, offset, ino 를 주면 buf 에 미리 약속된 형태(linux_dirent)로 적절히 넣어준다.
이 때 마지막에 d_type을 넣어주는데. 이것을 보고  block device, character device 인지 directory 인지 혹은 named pipe 인지 따위의 정보를 알 수 있다. 


http://linux.die.net/man/2/getdents 보면,
"Currently, only some file systems (among them: Btrfs, ext2, ext3, and ext4) have full support for returning the file type in d_type. All applications must properly handle a return of DT_UNKNOWN."


라고 되어있다.  


vfs code를 보다보니 Btrfs만을 위한 특별한 code가 들어있을 만큼 linux에서 Btrfs에게 신경을 써주는 거 같은데, 혹시나 이것도 그런 것일까? d_type 은 대체 무슨 이득이 있어서 넣어둔 것일까 궁금하다.